Serious performance problems (malloc related?)

[Andy Ross]

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.

Thanks,
Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygspd.cc
Type: text/x-c++src
Size: 1370 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20050528/e267a07a/attachment.bin>
-------------- next part --------------
--
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/