Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <42987F19.8070502@plausible.org>
Date: Sat, 28 May 2005 07:24:25 -0700
From: Andy Ross <andy AT plausible DOT org>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Serious performance problems (malloc related?)
References: <4297A14B DOT 9070409 AT plausible DOT org> <20050527234027 DOT GA7522 AT trixie DOT casa DOT cgf DOT cx> <4297B572 DOT 9050200 AT plausible DOT org> <20050528005054 DOT GB7522 AT trixie DOT casa DOT cgf DOT cx> <4297F984 DOT 3000800 AT plausible DOT org> <20050528061001 DOT GA9254 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20050528061001.GA9254@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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/