delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/10/05/07:39:44

Date: Tue, 5 Oct 1999 09:59:06 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: Reading directories, readdir/stat too slow
In-Reply-To: <37f9205f.sandmann@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.991005095847.2899P-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 4 Oct 1999, Charles Sandmann wrote:

> My solution was to cache the information from the findfirst/findnext calls
> (which contains date/time and size) and then the stat() call immediately
> finds this information in the cache.

Won't this break if the file changes on disk between the call to
readdir and the call to stat?  The two calls are independent, so
anything can happen between them, even on DOS (to say nothing about
Windows, where some other program may do it).  Unlike Unix
filesystems, DOS/Windows don't have any simple system call to check if
the directory contents changed, and invalidate the cache if it did.

These considerations were the main reason that I didn't implement such
a cache (although I have a prototype code that works).

FWIW, in a simple test program that just walks a directory tree in a
depth-first fashion, a single-entry cache like above slashes about
half of the run time--not a spectacular gain, but not a negligible
one, either.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019