Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3F96F8F6.8080900@tlinx.org> Date: Wed, 22 Oct 2003 14:39:02 -0700 From: "Linda W." Organization: what's organization? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en-ca, en-gb, en-nz, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin performance References: <3F957E0D DOT 2060405 AT tlinx DOT org> <20031021192854 DOT GG380 AT redhat DOT com> In-Reply-To: <20031021192854.GG380@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/