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
Am Freitag, 20. Januar 2012, 11:47:11 schrieb Daniel Santos:
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,
What happens when this process exits normally, but other processes still run?
oops, sorry I missed this one earlier Stefan. On my first mailing, all remaining processes simply stayed in memory waiting on the pipe, which also still existed (I ran a simple kill script to clean it up). However, I added a new atexit function that shuts down the master socket and all other programs terminate (as when you run wineserver -k). However, the socket & lock files still aren't cleaned up, so that issue is still outstanding.
So, in essence, termination of the primary application terminates the wine instance.
On 01/20/2012 02:31 PM, Stefan Dösinger wrote:
Am Freitag, 20. Januar 2012, 11:47:11 schrieb Daniel Santos:
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,
What happens when this process exits normally, but other processes still run?
-
Daniel Santos -
Stefan Dösinger