In-process wine server (a.k.a., "Dirty Speed Hack")

Daniel Santos danielfsantos at att.net
Fri Jan 20 11:47:11 CST 2012


Here's my hack after some cleanup, refinements and further
experimentation (mostly discovering what doesn't work).  It's still in
the early stages.

So I had this idea about 3 years ago and when playing Star Wars
Battlefront (1 and 2) and having such long load times that I couldn't
alleviate much by addressing the bottlenecks (the app spams
GetForegroundWindow and PeekMessageA while loading, hitting them each
22k times a second), I finally decided to give this hack a stab. So in
summary, loading new maps was taking 75 seconds under wine, where they
only take 10 to 15 seconds on windows (well, on my laptop, which is
slower than my desktop).  With this hack, they are down to 8 seconds
under wine, roughly 10x faster. 

This hack builds a libwineserver.so that the primary application (i.e.,
the one you first launch) will spawn a thread and run the wine server in
the same process, if you've set the environment variable
DIRTYNASTYSPEEDHACK.  Then, calls to the wineserver are made directly. 
Subsequent programs in the same WINEPREFIX will interact with your
process using the traditional pipes.

I don't have the build working the way it should, it currently only
builds the libwineserver.so when it builds the server (i.e., not built
when you configure with --with-wine-tools).  I'm not strong in
autotools, so if anybody cares to add this, I would appreciate it :)

Obviously, the trade off for this speed increase is that the stability
of your wine server (and thus, all apps running under that instance) are
based upon the stability of your program.  So with this enabled, your
program can crash the wine instance.  Also, while it addresses the slow
loading issues in Star Wars Battlefront II, it behaves very oddly in
regards to sound buffers being played correctly and HID input (if I move
the mouse slowly downwards, it will actually move slowly up).  These
problems go away when I debug it (I presume because the debugger is
slowing the program back down).

I'm going to try this out on a few other apps that run slow under wine
(like Finale 2010).

Daniel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 0001-Hack-for-in-process-wine-server-a.k.a.-Dirty-speed-hac.txt
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20120120/3bef4169/attachment-0001.txt>


More information about the wine-devel mailing list