http://bugs.winehq.org/show_bug.cgi?id=59765 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #2 from Zeb Figura <z.figura12@gmail.com> --- Usually wineserver per se isn't the bottleneck, only because RPC to wineserver is usually a bigger one. On old versions I believe an immediately satisfied recv() or send() takes only one server call; now two are necessary. Unfortunately avoiding these is hard. The fundamental problem is that I/O on the same socket has to be processed in the order that it's issued, which means we need something to be managing a queue, and since sockets can be cross-process, that needs to be the server. We need one server call to insert ourselves into the queue, and a second to remove ourselves after the I/O is satisfied. (Or, if we're not at the front of the queue, the first server call returns that status and we wait or return EWOULDBLOCK as appropriate.) Note that you can't special case nonblocking sockets, because you can still issue blocking I/O on a nonblocking socket using something like WSARecv(). In older versions of Wine, select() didn't take server RPC, but things have changed so now it's necessary for compatibility reasons. I don't remember the details offhand. I think an immediately satsifiable select takes one server call; one which has to wait takes two? Most applications aren't going to run into the corner cases that mattered, which is why things worked fine on 5.x. Most applications also don't care that much about socket I/O performance, I guess because the actual overhead of socket I/O is usually higher. If it's all loopback, I guess that might matter more. Unfortunately cutting the server out is going to be *very* hard. It'll take some thought. Still, it might be worth doing some more careful performance analysis on this, because the most obvious bottlenecks are also probably the hardest by far to remove. Counting calls can be misleading, so can perf, especially when there are multiple processes. I'd probably instead try to measure the time between cycles, and see how that's increased overall, as well as more fine grained differences e.g. how long select() takes including the sleep, how long send() takes, how long recv() takes... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.