RE: cygwin performance

["guenter strubinsky" <strubinsky at acm dot org>]

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
 
günter strubinsky
 <strubinsky@acm.org>

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: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf
> Of Linda W.
> Sent: Wednesday, 22 October, 2003 16:39
> To: cygwin@cygwin.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
> >puzzler.
> >
> >
> ----
>     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
> dissuade
> discussion about the _amount_ of overhead and whether or not it's really
> necessary
> 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
> feasible.
> 
>     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! :-)).
> 
> -l
> 
> 
> 
> --
> 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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/