Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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:	<429ED094.9080001@tlinx.org>
Date:	Thu, 02 Jun 2005 02:25:40 -0700
From:	Linda W <cygwin AT tlinx DOT org>
User-Agent:	Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Serious performance problems (malloc related?)
References:	<4297A14B DOT 9070409 AT plausible DOT org> <20050528131501 DOT V53507 AT logout DOT sh DOT cvut DOT cz> <20050528160424 DOT GB12395 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To:	<20050528160424.GB12395@trixie.casa.cgf.cx>
X-IsSubscribed:	yes

One area that I've noticed slowness is in using the 'find' command
to search for old "tmp" files or to rebuild the locate database.

In tracing the Win32 file operations, find seems to perform multiple
file open operations for each file processed.  One way to speed up
operations in this area might be to keep a "cache" of the last "N"
file handles.  I suspect it's just the Windows path lookup mechanism
being slow to reopen things.  But if the cygwin.dll could cache even
the past 5 entries, it might speed things up significantly.  If it
is opened each time to read different information, it might be much
cheaper to collect all the information at one time and cache it in
an internal "inode cache" that could expire in a second or so. 

If it would "slow" down other programs, it could have some smarts in
the system calls to look for calling patterns from programs like find
that need a couple or more openings to fully "process a file", that all
happen within a few milliseconds of each other.

BTW -- in case anyone is interested -- you can use the free Unix Services
for windows available for WinXP.  However, amusingling enough -- their
execution times are *slower* than cygwin's...  Of course MS might have 
deliberately used non-optimized methods for their services to convince
people to recode for the Win32 interface (and thus benefit by increased
Win32 lockin).

linda


Christopher Faylor wrote:

>Yep.  This is pretty much what I expected.  Now we'll see a stream of
>people commenting on slowness and speculating on the cause without
>spending any time to actually figure out what the cause might be.
>  
>
>Think of what a hero you'll be if you figure out a way to improve
>cygwin's "slowness".
>
>  
>

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

- Raw text -