Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Tue, 13 Feb 2001 14:35:08 -0500 Message-Id: <200102131935.OAA09136@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f From: DJ Delorie To: jik-cygwin AT curl DOT com CC: cygwin AT cygwin DOT com In-reply-to: <20010213190131.14369.qmail@lizard.curl.com> (jik-cygwin AT curl DOT com) Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() References: <4 DOT 3 DOT 1 DOT 2 DOT 20010213134821 DOT 019a7130 AT pop DOT ma DOT ultranet DOT com> <20010213190131 DOT 14369 DOT qmail AT lizard DOT curl DOT com> > I see three problems with that: > > 1) The cache would have to be automatically invalidated whenever the > 2) Many of our dependencies are checked over and over again in many > 3) The implementation of such a global cache would be much more I think an easier win would be to cache the bytes read within the fhandler, not globally, so while each fhandler (i.e. open, stat, whatnot) would still need to read the file itself, it would never need to read it more than once. If we still need more performance, perhaps a one-entry cache of the most recent file accessed (and when) could be added, and ignored if the data is more than, say, one second old. Even if it were local to one process, it would hit most of the usual cases (stat a file, alloc a buffer, then open/read the file). These should be easier wins (thus, more doable) than a global cache, which NT should be providing itself as part of the disk cache subsystem (for local drives, at least). I don't think it's appropriate for cygwin to go beyond this anyway - too many race conditions arise. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple