http://bugs.winehq.org/show_bug.cgi?id=6936
--- Comment #25 from Anastasius Focht focht@gmx.net 2007-11-27 18:56:05 --- Hello,
--- quote --- Thank you Anastasius for your analysis, it may well be the first step in the right direction, since this bug has been first reported almost a year ago. --- quote ---
Well, I noticed this bug id today, while looking for interesting bug reports ... consider yourself lucky ;-)
--- quote --- Is this behaviour fixable with a patch or is it inherent fault of wine and and emule that cant be sorted? --- quote ---
Well on both systems - windows and wine/linux - the same amount of idle messages is generated (actually WM_KICKIDLE and WM_TIMER).
To compare application performance between wine/linux and Windows, I use certain performance counters in Windows which reflect some operating systems aspects better than simple "CPU load". Namely "context switches", "context switch delta", "page faults" and "page fault deltas".
Technically Windows "cheats" when it comes to CPU load (task manager, process viewer and the like) ;-) Many threads run for such a short amount of time that they are rarely the currently running thread when the interval clock timer interrupt occurs and hence are not charged for their CPU time (resulting in zero CPU load).
By tracking certain performance counter values one can get a good impression what is going on under the hood ...
On Windows XP, the context switch delta ("thread activity") for emule is about 700-1200 per second with plain gui (no connections). A lot for an "idle" process. With a modal (options) dialog kept open, the context switch delta is usually around 650 transitions per second.
Windows makes a transition to kernel mode for each window handling call but does not seem to suffer performance-wise. The reason is simple: on modern CPUs, ring3 <-> ring0 transitions are usually carried out by "fast" system calls (special "sysenter" instruction), causing almost no CPU load. The wine client <-> server calls/transitions - including data transfers - are are much more "costly" (process boundaries by design) - resulting in performance penalty.
Although the amount of emule "idle processing" is somewhat questionable (that short paced idle intervals generate lots of unnecessary context switches) it is perfectly valid.
So this is actually a wine performance problem (client calling into server).
There aren't much options to fix this ... either reduce the amount of wine server calls/transitions by "caching" client calls/data (increases complexity and probably causes sync problems/race conditions) or optimize wine server code paths (difficult because process boundary remains). Unfortunately wine optimization has much lower priority than implementing new stuff/filling gaps/fixing bugs.
Another option would be to modify emule itself. AFAIK it comes with source code. With the right emule code modifications it should be possible to reduce idle message processing to create less overhead (wine server calls).
Regards
-
wine-bugs＠winehq.org