Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Message-Id:	<4.3.1.2.20010213140154.019d99c8@pop.ma.ultranet.com>
X-Sender:	lhall AT pop DOT ma DOT ultranet DOT com
X-Mailer:	QUALCOMM Windows Eudora Version 4.3.1
Date:	Tue, 13 Feb 2001 14:08:58 -0500
To:	jik-cygwin AT curl DOT com
From:	"Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject:	Re: Optimizing away "ReadFile" calls when Make calls stat()
Cc:	cygwin AT cygwin DOT com
In-Reply-To:	<20010213190131.14369.qmail@lizard.curl.com>
References:	<4 DOT 3 DOT 1 DOT 2 DOT 20010213134821 DOT 019a7130 AT pop DOT ma DOT ultranet DOT com>
	<4 DOT 3 DOT 1 DOT 2 DOT 20010213134821 DOT 019a7130 AT pop DOT ma DOT ultranet DOT com>
Mime-Version:	1.0

At 02:01 PM 2/13/2001, jik-cygwin AT curl DOT com wrote:
> >  Date: Tue, 13 Feb 2001 13:51:50 -0500
> >  From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
> >  
> >  I know this would only address half the problem but I wonder if it would make
> >  sense to cache the results of ReadFile() so that separate checks for symbolic
> >  links and executables would result in only 1 ReadFile() call.  This seems
> >  like a nice general optimization which wouldn't be so "gross"...
>
>I see three problems with that:
>
>1) The cache would have to be automatically invalidated whenever the
>    file is changed, and you'd thus need to check if a file has changed
>    before using the cache, and those checks would themselves take
>    time.


I'd submit that while this may be true in general, it shouldn't be in the
case of symbolic links and executables.  These attributes don't really change
or, if they do, they change in a very defined way which should make it 
possible to track.


>2) Many of our dependencies are checked over and over again in many
>    Makefiles by many different Make processes.  Thus, either the cache
>    you propose would have to be global in the Cygwin shared memory
>    segment, or the checks would still happen over and over for us.


Right.  Having it in shared memory would be almost a requirement as far
as I can see.


>3) The implementation of such a global cache would be much more
>    complex then the simple changes I implemented in only a couple of
>    hours, and I would argue that this complexity would in fact make
>    such a cache *more* "gross" than the changes I'm suggesting.


I'm not necessarily suggesting this as a replacement for your changes.
I'm just trying to think of how this problem could be attacked in general.
Whether or not your changes are accepted into the baseline, a general 
solution would benefit every app.  Mostly, I'm just thinking out loud (with
the intent of having people poke holes in the idea...)



Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -