Best Wine version for 32bit applications (Debian 10.6)

[nxt5577]

HI .
I have some older 32 bit applications (non graphical intensive) and I want to run as many instances a possible. This means I need wine to use as little CPU as possible. This is what I noticed (I just use apt-get install without any tweaking):
All running under Debian 10.6 64bit.

Wine 4.0 (wineserver32 seems to be running)
Wine 5.0.3 (wineserver64)
Wine 5.22 development (wineserver)

I don't have 3 servers to run all 3 setup at the same time to compare CPU usage but winserver32 seems to be using 50% CPU of 4 core CPU and 5 instances of the 32bit application is running. Wine seems to choose the type -wineserver32/64 or just wineserver by default install.

So in 'theory' which of the wine version is more cpu efficient in running 32 bit applications (non graphical intensive).? I do notice v5.22 uses the most RAM but I am more concern about CPU. I do realize that recent development of wine has been on catering for the gaming community which benefits all users but I still have some old 32bit windows program that still in use.
Thanks

[spoon0042]

32- vs. 64-bit shouldn't matter, wine will use its 32-bit parts either way for a 32-bit .exe.

Beyond that it's hard to say and could vary depending on what exactly your programs are doing. The naive assumption might be that the earliest wine version that runs your programs correctly might use the least cpu since generally speaking the devs focus on correctness more than performance. But performance improvements do happen.

You may have to just try different versions and see what happens. The 'time' bash builtin may help, or other performance tools if you want. Perhaps building wine yourself with optimizations could help. Or you could spend more time finding out than you end up saving.

[nxt5577]

Thanks spoon.
When I started using wine 1.9 years ago, the cpu usage was minimal, but now it is getting bloated. But we need to stay as up to date as much as possible.
wine v5 stable seems to less efficient in terms of CPU usage compared to v4 based on my initial testing. i.e. winserver32 uses less CPU than winserver64 for my application.

[nxt5577]

I had another test with latest wine 6.0 development.
Wine 6.0 uses the same RAM and CPU as wine 4.0 but the 32 bit application uses more RAM (from 140K to 200K). Since I am running multiple of these instances, it chew up quite a bit of RAM.
So I decided that I will stay with wine 4.0 for my applications.

[nxt5577]

just another update on my un-scientific observation:

I install iceWM without display manager. The response is very laggy. When I minimized the applications window, you can see the jerkyness when it closes. Also when I maximized it again, it shows a black screen and took up to 45 seconds before the screen display.

Next I install Xfce4, also without display manager (I setup .xinitrc in both cases to start the GUI).
Xfce4 uses more ram but it has a slight performance advantage, it is less laggy and the display screen appears about 15 seconds after I maximized it.
Note: The application is a normal windows application, non graphic heavy.

I use VNC to access the server in both cases and 5 instances of the application running. 2.5gb RAM, 3 vCPU. Ram usage in both cases are between 1.05 GB (iceWM) and 1.2 GB(Xfce4).

Of course when running on Windows server 2012R2 and using remote desktop, there is no lag at all like a normal desktop. RAM usage is under 1GB.

Any other windows manager I should try? I need the applications autostart when server boot. I find both icewm has less steps to setup autostart compared to xfce4.
I use WINEDEBUG =-all in the icewm start up script but for Xfce4, the .desktop content doesn't allow this. Is this correct or have I missed something.

[spoon0042]

I use WINEDEBUG =-all in the icewm start up script but for Xfce4, the .desktop content doesn't allow this. Is this correct or have I missed something.

Are you using 'env' to set any variables, that's what .desktop files created by wine use. Should look like this I think:

Code: Select all

Exec=env WINEDEBUG=-all wine C:\\\\path\\\\goes\\\\here\\\\program.exe arg1 arg2

(WINEPREFIX would go there as well if needed.)

[nxt5577]

Thanks Spoon.
Use env seems to solve the problem and I use softlink from autostart and it works (it didn't work the first time but after unlinking and trying hardlink which works, I redo the softlink and it works the second time).

I guess what is left is for my to try out KDE to see its graphic libraries will provide faster response time. Looks like KDE and XFCE4 uses the same autostart folder which means just removing XFCE4 and installing KDE and .xinitrc settings is all I need to do.

Is there any other windows desktop that I should consider?

[spoon0042]

Is there any other windows desktop that I should consider?

You might consider using just a window manager rather than a desktop environment if even xfce isn't "lightweight" enough. There's a bunch of options and some (like openbox) don't really do anything more than manage windows and provide a right click menu. Some are "smart" about window placement or are configurable if that's something you'd find useful and have time to kill trying some out.

[nxt5577]

I came to the following conclusion after testing for a month
The choice of windows manager (iceWM, Xfce4,KDE) doesn't matter, the application interact with Wine which interact with the libraries
App--> wine--> GTK/QT. The slowness in the application basic GUI response is due to efficiency(or inefficiency) of Wine. The windows manager response time while application is running is still acceptable.
But the application takes time to display which means it is CPU bound. So choosing a lightweight windows manager to save some RAM is of no consequence.
MS Windows may consume higher RAM for a base install but each instance of the application consumer less RAM(and less CPU) vs using Wine which has lower RAM on base install. But each instance uses 100K more RAM (and more CPU)than MS Windows instance
So from an architectural perspective, MS Windows design has more shared resources.