Thanks very much Jeff, for providing some independent timing numbers for startup latency which are an order of magnitude (!) smaller than mine. So what is different about our wine platforms to cause that huge difference? More below.
On 2010-06-19 12:55+1000 Jeff Zaroyko wrote:
Windows: $ time gcc --version gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
real 0m0.020s user 0m0.000s sys 0m0.015s
Wine: jeffz@genera:~$ WINEPREFIX=/home/jeffz/wine-cpbench time ~/git/wine/wine "c:\mingw\bin\gcc" "--version" gcc.exe (GCC) 3.4.5 (mingw-vista special r3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
0.00user 0.01system 0:00.02elapsed 66%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+1567minor)pagefaults 0swaps
So to the level of your measurement precision you are consistently getting 20 ms elapsed time for both Windows and Wine for the gcc --version experiment on boxes very similar to mine. For the same experiment (I went out of my way to use the same syntax you did) I am getting ~150 ms for one X server and ~300 ms for the other. So that is an order of magnitude difference in our results. When I can reduce my wine application startup latency to 20 ms, I will be a happy camper, but the question is how can I do that?
One difference between us is I am using MinGW-4.5.0-1, but it is hard to believe that the time taken to process the --version option for that has changed so drastically from your gcc-3.4.5. Also, I believe the startup latency on my platform is a general problem on my platform and nothing to do with gcc. I get essentially identical startup latency results with "mingw32-make --version" and "gcc --version". "cmake --version" tends to be about 10 per cent longer than the other two. Presumeably you have convenient access to mingw32-make. Do you also get only ~20 ms startup latency for that?
How about file systems? My experiments were done on ext3. What filesystem were you using on the box where you did the wine timing experiment?
The other thing that bothers me is I get the same identical result whether wineserver is active or not. Can you confirm that for your wine timing experiment or is that an unusual result?
Other data here that may be relevant to the comparison with you:
My hardware is 64-bit.
Linux raven 2.6.26-2-amd64 #1 SMP Wed May 12 18:03:14 UTC 2010 x86_64 GNU/Linux
I am running 32-bit wine (wine-1.2-rc3 compiled with the -O3 option for Debian Lenny) which uses the following libraries:
irwin@raven> ldd /home/software/wine/install/bin/wine linux-gate.so.1 => (0xf77a2000) libwine.so.1 => /home/software/wine/install/bin/../lib/libwine.so.1 (0xf765d000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7625000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libdl.so.2 => /lib32/libdl.so.2 (0xf74ce000) /lib/ld-linux.so.2 (0xf77a3000)
Previously, I got ~50 per cent larger startup latency numbers with the Debian Lenny package for wine-1.1.42 provided by WineHQ which is why I switched to to building my own wine-1.2-rc3, but 150 ms with the latter just doesn't cut it compared to your 20 ms.
Let me know if there is any additional comparison data I can provide. For me the important question is what is fundamentally different between our two software platforms or wine configurations that causes this order of magnitude difference in startup latency on similar hardware?
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 __________________________