Serious performance problems (malloc related?)

[Andy Ross]

Christopher Faylor wrote:
> Ok.  I tried it.  I did not notice anything like what you described.
> I saw no indication that malloc was being called after the original
> startup.

Dunno, the STL vectors need to copy the new strings somewhere,
certainly.  Is the operator new pointed at something other than
malloc?  I suppose it's possible that there's some second-level
allocation work being done inside the STL...

> I saw consistent (implied) ~3 millisecond waits for disk reads.

But as I noted in my original post: It's not waiting on the disk
reads.  Comment out the split() call and watch the delays disappear.
Raw I/O speed in cygwin is comparable to mingw or MSVC.  The overhead
is due, somehow, to activity within/under split().  Other than
allocation, that function doesn't do any meaningful library
interaction that I can see (although Vaclav's suggestion about
exception handling is a very good one...).

I'll point out again: this isn't just an issue of poorly optimized
code.  Something is spending 93% of the time in this program doing
literally nothing inside those odd delays; if you take the delays out,
you get performance on par with what you see on other platforms.  That
indicates to me that this is a synchronization bug.

I won't have a win32 box available to test with until after the
weekend, though.  I know you'd prefer that I spend my own time working
on this, but like I said this really isn't my platform.  I got
involved trying to help out FlightGear users who are really being hurt
by this issue.

Andy


--
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/