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
Date:	Thu, 2 Jun 2005 13:22:26 -0400
From:	Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Serious performance problems (malloc related?)
Message-ID:	<20050602172226.GC6597@trixie.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
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> <429ED094 DOT 9080001 AT tlinx DOT org> <Pine DOT GSO DOT 4 DOT 61 DOT 0506021301320 DOT 10282 AT slinky DOT cs DOT nyu DOT edu>
Mime-Version:	1.0
In-Reply-To:	<Pine.GSO.4.61.0506021301320.10282@slinky.cs.nyu.edu>
User-Agent:	Mutt/1.5.8i

On Thu, Jun 02, 2005 at 01:02:30PM -0400, Igor Pechtchanski wrote:
>On Thu, 2 Jun 2005, Linda W wrote:
>>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.
>
><http://cygwin.com/acronyms/#SHTDI>.
><http://cygwin.com/acronyms/#PTC>.

Oddly enough, Corinna and I have been discussing the possibility of
caching opendir/readdir data for subsequent use in stat().  She's for it
and I'm mildly agin' it.

I think that introducing caching opens the door to all sorts of subtle
race conditions since only the OS can maintain cache coherency.

She thinks that the benefits would outweigh the tiny possibility of bad
cache data resulting from something like performing an "ls" on a file
and having, e.g., some other process sneak in, remove the file and
introduce a directory, but still having "ls" report file data.

There are, of course, other more serious races possible as soon as you
introduce user mode caching of file data...

I thought I should mention this in the off chance that Corinna actually
does implement something just so that history records that this is
something that Corinna has been considering for a while.

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/

- Raw text -