Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sat, 28 May 2005 02:10:01 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Serious performance problems (malloc related?)
Message-ID: <20050528061001.GA9254@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4297F984.3000800@plausible.org>
User-Agent: Mutt/1.5.8i

On Fri, May 27, 2005 at 09:54:28PM -0700, Andy Ross wrote:
>Christopher Faylor wrote:
>>Gee, I'm sorry you thought I was being "snippy".  You apparently missed
>>that I was just providing you with some obvious advice.
>
>Indeed.  To paraphrase: "Fix it yourself, not my problem."

Actually, I think I implied that you should "learn more about cygwin"
and that you should "instrument it yourself".

I should also have said "check out http://cygwin.com/problems.html ".
This would have provided you with some more details to provide like
the important one of providing cygcheck output.

>> It seems like if this was a really serious problem you'd be actively
>> working towards solving it rather than sending out email and hoping
>> to get lucky.
>
>You mean, like the several hours it took to get from "FlightGear
>startup is slow" (on a platform I don't use) to the freakishly obvious
>sample code I sent you that you didn't even bother to try?

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.  I saw consistent (implied) ~3 millisecond waits for disk
reads.  I saw no indication of malloc activity once the reads started.

>The saddest part of all of this was when I actually did go to the CVS
>to look at the malloc synchronization and discovered that *YOU* are
>the author.  So much for getting this fixed any time soon.  Not my
>platform, not my problem.

Yes.  I'm the author of a large percentage of the code in cygwin.
malloc synchronization is a "muto" in cygwin.  I wrote the muto
implementation.  I wrote it to theoretically speed up the previous
implementation.  I really don't think that has anything to do with this,
however.

>Someday, you might actually care about why cygwin is so much slower
>than linux (or windows, or mingw) on the same hardware.  When you do,
>you know where to find your test case.  Maybe there are some other
>developers around that might want to help.

It is a very well known fact that cygwin is slow.  I know several
reasons why cygwin is slow.  There are undoubtedly many that I'm not
aware of.

>Again, just in case you aren't clear or if someone else wants to
>inject some sanity into the conversation: Cygwin is SLOW AS MOLASSES
>(literally: fifteen times slower than mingw or glibc) when doing
>obscure tasks like reading lines, splitting them into fields, and
>allocating memory to hold the strings.
>
>This is probably also why Cygwin is so much slower than linux or mingw
>at so many other tasks.  That you don't think this is a problem is
>just beyond me.

Again, I'd suggest that you spend a little more time looking at the
problem and instrumenting parts of the code that you think are giving
you problems.  You should probably take c++ out of the equation, too.
There's no way of knowing if something in c++ is causing the problem
that you're seeing.

All that I'm asking you to do is prove your *guess* that this is a
malloc problem.

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/