From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9910051657.AA15777@clio.rice.edu> Subject: Re: Reading directories, readdir/stat too slow To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Tue, 5 Oct 1999 11:57:43 -0600 (CDT) Cc: djgpp AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Oct 5, 99 09:59:06 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Won't this break if the file changes on disk between the call to > readdir and the call to stat? I used a single file element cache, and invalidated it on any other dpmi_int call. I assumed it was a snapshot. > 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. I wasn't trying to protect against all the possible cases. But I did need a 50X speedup. It worked on all code except unix ports that assumed a unix file system (inodes, etc). > 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. A lot of the stuff which causes readdir/stat to be slow isn't needed for the typical application - if you look at the minimal calls to do readdir/stat for portable structure entries (no inodes, etc) you get this from the single findfirst/findnext call - and thus almost identical speed. It all depends on what you need - I needed to quickly find files on a very large disk - written with portable code.