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/
