This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Serious performance problems (malloc related?)

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 ".
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,

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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]