Darren Reed wrote:
> 
> How much code (and how slow is it) reads in a directory and then stat's
> every object?  How much could be gained by having a system call which
> read in a directory and returned an array of names and stat structs?

Probably not much of a gain....
Are you sure it is the stat() that is taking all the time?
The system call overhead isn't that large, so all you can possibly gain
is overlapping processing of one entry with the reading of the nest.
> 
> Or even another thought might be to schedule (at a very low priority,
> and one which allows requests to be thrown away before they get run)
> reading in dinodes for all entries in a directory after the directory
> contents have been read.
> 
> This maybe really stupid (because the names and dinodes don't co-exist
> in the same space, on disk) but it can't hurt to ask others about what
> they think of this :)  Heck, they're probably really dumb ideas but it
> can't hurt to share them, can it ? O:-)
> 
> What prompted me to ask?  Reading someone saying write "Konquerer took
> forever to display a large directory on Linux" and then say "Explorer
> windows popped up almost instantly".

What may be taking the time - and it was the limiting factor of mkisofs
on one system I used - is how long it takes to convert the file date to
printable format.  Exploder wont be doing any of that (because it
doesn't support timezones).

I had a feeling that stat() was slow because it had to return things
that were not available in the inode (eg the amount of free space on the
disk).  Neither the netBSD nor Solaris man pages include that field
though, dunno what the code does.

The Unixware VOP_GETATTR function (that underlies stat) has a bitmask of
required values, dunno it netBSD has the same.

There are cases where programs seem to call stat() for the hell of it! 
It is hardly any mode expensive to open a file than to stat it.  I'm not
sure, but I think 'find' could just try opendir() on all the names,
shells seem to stat files instead of just opening (oe execing) them...

	David