![그렇다면 클라이언트와 서버를 분리하는 설계는 X Window의 병목 현상이 아닌가?](https://linux55.com/image/31877/%EA%B7%B8%EB%A0%87%EB%8B%A4%EB%A9%B4%20%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%EC%99%80%20%EC%84%9C%EB%B2%84%EB%A5%BC%20%EB%B6%84%EB%A6%AC%ED%95%98%EB%8A%94%20%EC%84%A4%EA%B3%84%EB%8A%94%20X%20Window%EC%9D%98%20%EB%B3%91%EB%AA%A9%20%ED%98%84%EC%83%81%EC%9D%B4%20%EC%95%84%EB%8B%8C%EA%B0%80%3F.png)
대답으로이것, 다음 내용이 언급되어 있습니다.
사람들은 또한 X가 "네트워킹"을 사용한다는 말을 듣고 이것이 성능 병목 현상이 될 것이라고 생각했습니다. 여기서 "네트워크"는 현대 Linux에서 무시할 만한 오버헤드가 있는 로컬 UNIX 도메인 소켓을 의미합니다. 네트워크에 병목 현상이 발생하며 작업 속도를 높일 수 있는 X 확장(공유 메모리 픽스맵, DRI 등)이 있습니다. In-process 스레드는 반드시 X 소켓보다 빠르지는 않습니다. 병목 현상은 로컬 소켓의 최소 오버헤드보다 동일한 하드웨어에 액세스하는 여러 스레드 또는 프로세스를 조정하는 고유한 문제와 더 관련이 있기 때문입니다.
그러나 나는 공유 변수를 통해 통신하는 다중 스레드가 Unix 도메인 소켓을 통해 통신하는 다중 프로세스보다 더 빨라야 한다고 항상 생각했습니다. 그럼... 내 말이 틀렸나? 여러 스레드를 조정하는 데 시간이 많이 걸리는 작업인가요? 프로세스가 획득하는 순서예정됨Unix 도메인 소켓의 성능에 전혀 영향을 미치지 않습니까?
어떤 아이디어가 있나요?