Mail Archives: cygwin/2005/05/28/10:24:20
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/
- Raw text -