Mail Archives: cygwin/2005/05/27/19:40:44
On Fri, May 27, 2005 at 03:38:03PM -0700, Andy Ross wrote:
>At FlightGear, we have a bunch of users building on Cygwin as their
>environment (MSVC and mingw builds are possible but non-trivial, and
>the configure scripts work out-of-the-box on cygwin) and complaints of
>performance problems have been persistent. When it was recently
>pointed out that the simulator starup on Cygwin was 10-20 times slower
>(10 seconds vs. several minutes!) than under Linux or a MSVC build, I
>had to take a look. :)
>
>Try the attached C++ file. It's a pared down version of one of the
>initialization steps we do at startup (reading a giant database of
>airports, although that's not particularly important). All it does is
>read the file line-by-line and run it through a split-on-whitespace
>function. It takes *vastly* longer to complete when linked against
>cygwin.dll than when compiled against the native C library with
>-mno-cygwin.
>
>If you watch the process with strace (the second field shows
>microseconds since the last line), you will see that most I/O reads
>complete in just a few tens of microseconds. But every N reads*,
>there is a rogue, inexplicable delay of several milliseconds. Since
>only a few blocks have completed by the time they happen, these delays
>represent maybe 95% of the execution time, which happens to match the
>cygwin.dll performance overhead very closely.
>
>* N == 4 on my machine running this test code, but ~10 running the
> actual FlightGear binary.
>
>My guess, having zero knowlege of cygwin.dll (remember I'm a linux
>guy), is that something in the malloc implementation is spinning
>needlessly on a synchronization primitive, or something of the sort.
>
>Note that the problem is not I/O overhead -- if you remove the split()
>call, the program completes very quickly. It seems to be something
>related to the allocation done in split().
>
>Anyway, any help would be appreciated. This really is a rather
>serious problem. We have some users waiting three minutes for the sim
>to start. While I would obviously prefer they upgrade to Linux to
>avoid this problem, in the real world I suspect we're likely to be
>losing users instead.
It seems pretty clear to me that if this is a really serious problem for
you then the best way to get it fixed is to gain more than zero knowledge
of cygwin. That's what the two main project contributors did when they
had problems with cygwin.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -