그렇다면 클라이언트와 서버를 분리하는 설계는 X Window의 병목 현상이 아닌가?

그렇다면 클라이언트와 서버를 분리하는 설계는 X Window의 병목 현상이 아닌가?

대답으로이것, 다음 내용이 언급되어 있습니다.

사람들은 또한 X가 "네트워킹"을 사용한다는 말을 듣고 이것이 성능 병목 현상이 될 것이라고 생각했습니다. 여기서 "네트워크"는 현대 Linux에서 무시할 만한 오버헤드가 있는 로컬 UNIX 도메인 소켓을 의미합니다. 네트워크에 병목 현상이 발생하며 작업 속도를 높일 수 있는 X 확장(공유 메모리 픽스맵, DRI 등)이 있습니다. In-process 스레드는 반드시 X 소켓보다 빠르지는 않습니다. 병목 현상은 로컬 소켓의 최소 오버헤드보다 동일한 하드웨어에 액세스하는 여러 스레드 또는 프로세스를 조정하는 고유한 문제와 더 관련이 있기 때문입니다.

그러나 나는 공유 변수를 통해 통신하는 다중 스레드가 Unix 도메인 소켓을 통해 통신하는 다중 프로세스보다 더 빨라야 한다고 항상 생각했습니다. 그럼... 내 말이 틀렸나? 여러 스레드를 조정하는 데 시간이 많이 걸리는 작업인가요? 프로세스가 획득하는 순서예정됨Unix 도메인 소켓의 성능에 전혀 영향을 미치지 않습니까?

어떤 아이디어가 있나요?

관련 정보