那么客户端 - 服务器分离的设计不是X Window的瓶颈?

时间:2013-05-12 12:32:01

标签: client-server ipc scheduling x11 context-switch

this的答案中,它提到:

  

人们也听说X使用“网络”并认为这是可行的   是一个性能瓶颈。 “网络”在这里表示本地UNIX域   socket,在现代Linux上的开销可以忽略不计。那件事   会在网络上出现瓶颈,有X个扩展可以快速完成   (共享内存pixmaps,DRI等)。进程中的线程不会   必须比X套接字快,因为瓶颈有   更多地与协调多个线程的固有问题有关   或进程访问相同的硬件,而不是最小的   本地套接字的开销。

我不明白。我一直认为通过共享变量进行多线程通信应该比Unix域套接字通信的多个进程更快。所以......我错了吗?协调多个线程是一项耗时的工作吗?进程如何获得scheduled的顺序根本不会影响Unix域套接字的性能?

有什么想法吗?请...


对不起,我没有说清楚问题。我想问的是IPC效率而不是X Window / Wayland系统。

我只是想知道为什么UNIX域套接字可以比共享内存更快? AFAIK,共享内存是进程和线程之间最原始的通信方式不是吗?所以UNIX域套接字应该建立在共享内存机制之上(伴随着正确的锁定)。为什么学生(即Unix域名套接字)能胜过他的老师(即共享内存)?

1 个答案:

答案 0 :(得分:0)

对于表现来说,重要的是最慢的事情(瓶颈)。如果程序的某些部分可能更快,但它不是瓶颈,那么修改程序的那部分将无济于事。

这就是为什么提高性能应始终从分析开始。程序的每一位都可以更快,但你需要更快地使瓶颈,而不仅仅是一些随机的东西。

使用X,人们通常会接触到简单的洞察力,即如果在一个进程中,套接字上的某些东西总是会稍微快一点。这是事实,但它并不一定重要整体表现。更重要的是系统的整体设计......这就像Wayland正试图修复的那样。