https://bugs.winehq.org/show_bug.cgi?id=45121
--- Comment #14 from Etienne Dechamps etienne@edechamps.fr --- Out of curiosity I ran Steam under an API tracer on a Windows 10 machine and, to my surprise, I saw the exact same thing as I saw in the wine relay logs. It's doing the same busy loop even under native Windows. So the busy loop itself is *not* the consequence of a Wine bug.
This is starting to look like poor design on Steam's side. That being said, on native Windows the CPU usage from that thread is much lower. What I suspect is happening is: the calls in question might be cheaper on Windows than on Wine; and/or Windows might make the thread sleep for longer during the Sleep(0) calls that Steam makes on each iteration.
I used the Windows Performance Toolkit on the Windows machine to investigate further. On native Windows, the thread in question iterates at roughly the same rate (~1000 times per second) than on my Wine setup, but each iteration is very quick - about 42 µs on average. This leads to about 4% utilization of a single CPU. The Windows Task Manager will show an even smaller number because, contrary to "top", it divides CPU usage by the number of CPUs, which might contribute to the perception that the CPU usage is lower than on Wine.
I haven't checked how long the iteration takes on my Wine setup, but judging from the CPU usage numbers I'd estimate it's at least 4 times slower. The Win32 functions being called have likely been optimized to death on native Windows, but on Wine they have to go through several round trips to the wineserver, which involves context switches etc.
As for fixing this problem, I can see a few possible avenues at this point: - Ask Valve to fix their poorly designed busy loop. (Good luck.) - Optimize the Wine implementation of the offending Win32 calls. (I don't know, caching maybe?) - Implement some kind of clever Steam-specific workaround where Wine detects that it's being called from that loop and deliberately throttles it (e.g. by changing the Sleep(0) call to Sleep(10ms), which would reduce CPU usage by a factor of ~10).