Speed/latency issues for development in a Wine environment

[Alan W. Irwin]

Hi Paul:

Thanks for your ideas on reducing the command startup latency.

On 2010-06-18 10:48+0300 Paul Chitescu wrote:
> Alan,
>
> Try to keep the wineserver initialized and running - for example keep a
> cmd.exe or notepad or something idle (in the same WINEPREFIX).

I tried that by running

wine cmd

in another xterm (but the same WINEPREFIX) and left it idle at the command
prompt rather than exiting.  That made no significant difference to the
startup latency timing results.  I then tried the experiment of turning the
wineserver off (wineserver -k).  I double-checked that nothing was running
wineserver by using "ps auxww".  I also made sure there were no other idle
wine commands running.  For that experiment, the startup latencies still
remained the same!  So either I am not running wineserver properly (I use
wineserver -p) or it makes absolutely no difference to simple commands that
essentially do very little such as the three "--version" ones I am using to
test startup latency.

> To get more accurate timings run the test twice so the 2nd time the files
> should be cached in memory.

Always.

>
> If you are _sure_ you don't need a GUI you can unset DISPLAY (or run in a pure
> text console) so wine won't be able to create any windows. But the fact the X
> server matters suggests that some GUI components are used after all.

The cmake and MinGW gcc and make commands are all pure command line. So I
tried setting

DISPLAY=

and that actually made a small but significant reduction (a drop from near
~150 ms to ~125 ms on average for the --version option for those three
commands) in the startup latency.  Therefore, I think the conclusion must be
that command startup under wine initializes GUI components even when they
are not needed.  I will test this hypothesis further by disabling X
altogether by configuring a stripped-down build of wine and doing further
command startup latency tests with that stripped-down version of wine.

>
> Also please verify how fast gcc is to start on Windows, it may not be a wine
> problem. On Windows it is typically more expensive to start processes so
> Windows programs are usually more complex, do more tasks (eventually
> multithreaded) and live longer than the average UNIX program.

That would be a most interesting comparison.  In computer terms 150 ms is an
absolutely enormous time that allows something like 150 million (!)
operations to occur on modern PC's.  So I would be surprised if Microsoft
Windows required that long to start up applications.  However, I would need
help from others here to report command startup times under Microsoft
Windows since I don't have access to that platform.  The average of the
times to run the commands "gcc --version", "cmake --version", and
"mingw32-make --version" should be a pretty good measure of command startup
time.  Ideally, of course, these Wine versus Microsoft Windows startup time
comparisons should be made on the same box, but we are looking for orders of
magnitude here (The Linux startup times are two orders of magnitude lower)
so I don't think this strict "same box" requirement is necessary so long as
the boxes are roughly the same (mine is a garden-variety dual-core Intel 2.4
GHz).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________