Mail Archives: djgpp/1999/10/05/14:45:43
> 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.
- Raw text -