This is the mail archive of the
mailing list for the Cygwin project.
RE: cygwin performance
- From: "guenter strubinsky" <strubinsky at acm dot org>
- To: <cygwin at cygwin dot com>
- Date: Wed, 22 Oct 2003 18:04:08 -0500
- Subject: RE: cygwin performance
Thank you for the perl tip, Linda. I would have never dreamed (ergo never
tried) that the big-butt (PG rated term) perl engine would run faster than a
chain of miniature programs. Well, back to the good ol' perl manuals.
with kind regards
p.s. when I was a college prof I always reminded my students, that there are
no stupid questions, only stupid answers.
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf
> Of Linda W.
> Sent: Wednesday, 22 October, 2003 16:39
> To: email@example.com
> Subject: Re: cygwin performance
> Christopher Faylor wrote:
> >On Tue, Oct 21, 2003 at 11:42:21AM -0700, Linda W. wrote:
> >>Has anyone done any testing on performance of cygwin utils over their
> >>native win counterparts?
> >Cygwin is slower. Cygwin is known to be slower. And, if you give it
> >a few minutes of thought it is obvious why Cygwin has to be slower.
> >I assume that anyone who doesn't understand why cygwin programs have to
> >be slower than normal windows programs also complains bitterly about the
> >loss of power in their VW Bug since they started pulling a trailer
> >around everywhere they go. What's up with that? That's the real
> Well, it's more like I have a 6-cyl van and add in a 5gallon
> (~40lbs) to haul around
> but having the van accelerate like you've added 400lbs rather than 40.
> Yes, there is going to be some obvious overhead in emulating the
> calls, but by
> just saying "emulation causes overhead. Expect it. Case closed.", you
> discussion about the _amount_ of overhead and whether or not it's really
> to be as slow as it is.
> If it's the best that can be done -- fine. But has anyone given the
> issue any
> thought? _I_ don't know.
> I'm just relating a noticable experience with slowdown that might
> put off Window's users
> from "trying" gnu-based utils: "Gee why would I want to use gnu/linux
> like utils...they're about
> 10x slower than doing it with native tools".... Not the best "PR".
> It's hard for me to "sell"
> or "recommend" the Cyg-utils as an superior (even if they are)
> alternative to he win-utils when
> I might get my hand slapped at the first performance comparison they
> do. So I'm just
> asking the questions....didn't mean to touch a 'nerve' and it wasn't
> meant as a criticism --
> it's just an engineering question -- why would a simple file-name search
> using find need to
> do 2 opens/file? Is there a way to 'cache' recently opened files to
> optimize situations where
> someone does a stat or two in a row? Perhaps Cygwin could maintain a
> cache of opened win
> file descriptors and time them out after a second or two. I don't
> know. Maybe it's not technically
> But resorting to comparing me to someone who doesn't know why a VW
> bug slows down
> pulling a 4-ton trailer (assuming the engine didn't burn out) is a
> _slightly_ "tinged" insult. One
> might think that to elicit such a response, one might have had to have
> hit a 'nerve'. It wasn't
> intended that way. Code is code. There are only problems waiting to be
> solved. What was
> good code 20 years ago might be considered terrible today. Hindsight is
> often '20/20'. And
> usually, people make the best decisions they can at the time with the
> resources and knowledge
> available to them. I know there are many things I might do differently
> had I known what I know
> now (stock investments might be familiar examples of that category to
> many people :-)), if only
> we could jump back in time and 'redo' things...like that girl on
> Andromeda...or that one
> ST:NG episode where they got stuck in a timeloop getting destroyed each
> time...a beneficent
> timeloop -- that doesn't let them go until they are not destroyed (so we
> can continue the
> episodes, of course! :-)).
> 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/
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html