[Wine] Speed/latency issues for development in a Wine environment

[Alan W. Irwin]

On 2010-06-12 01:51-0500 DanKegel wrote:

> I've done a number of similar builds
> ( see http://wiki.winehq.org/UnitTestSuites )

That's an interesting idea, but I would suggest taking it a lot further with
WineHq providing the facilities to report testers build efforts rather than
having them scattered over the different projects.  In particular
CMake-based build systems (such as for KDE and many other projects such as
PLplot, and CMake itself) have a ctest facility that allows interested users
to report nightly test results to a simple dashboard hosted anywhere.  So
there is a huge amount of potential here with projects with CMake-based
build systems to have a central reporting facility at WineHQ that
automatically publishes all users nightly build test efforts to the web.

There is a big caveat at the moment, however, for this idea. Many/all
versions of CMake up to and including the latest, 2.8.1 use a
GetShortPathName() / GetLongPathName() trick to get the actual case for a
filename, and that generates a hash collision between the names of two CMake
language-support files (see http://bugs.winehq.org/show_bug.cgi?id=22286).

<aside> I think this was dismissed as CMake just being unlucky in their
choice of file names, but an alternative explanation is that the
GetShortPathName hash function is poorly implemented within Wine so the
probability of collisions is higher than it should be.
</aside>

CMake has now replaced that trick in their git version by code that does not
call GetShortPathName (see
http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3).
Until the corresponding patch (located at
http://cmake.org/gitweb?p=cmake.git;a=patch;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3)
becomes part of an official CMake release, you can bootstrap a patched CMake
under Wine by renaming the file with the hash collision (which disables
Fortran support) so that CMake can build a full patched version of itself
(which includes Fortran support).  Anyhow, that's the method I am using for
my own CMake/MinGW/Wine tests, and why a Wiki cookbook (still being written)
is fairly essential for anyone else trying to follow me before the patched
version of CMake is released.

> and agree Wine is slow at running builds.
> See in particular
> http://bugs.winehq.org/show_bug.cgi?id=21423
>
> Please file an enhancement request at http://bugs.winehq.org with your test data, perhaps your bottleneck is different.

Will do.  To summarize the situation, you have found file access times are
slower on Wine than Windows (and presumably also slower on Wine than Linux).
I have found that every simple command I try under wine (such as "cmake
--version", "gcc --version", and "mingw32-make --version") all seem to have
a large startup latency near 0.25 seconds that cannot be associated with
file access times. So I expect both your timing tests and mine for building
software under Wine see a combination of the startup latency issue for the
thousands of commands that are run in a typical build as well as the file
access time issue.

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
__________________________