--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 15, 2002 at 01:26:11PM +0900, Daniel P. Zepeda wrote:
> I think we're talking about apples and oranges here. Your code walks the
> entire filesystem tree in two tenths of a second? I think not.

Indeed.  For my whole system of 280533 files and 17820 (approx 35GB)
directories 0.2 seconds works out to be about 700ns per file, or 11000ns
(.011ms) per directory, whichever way you want to count.  This seems really
quick in terms of IO, where my guess would be that at the least 25% of the
accesses would be not cached and not contiguous to any other accesses happening
around the same time.  Not to mention overhead of each OS call (esp if
something else is going on on the system), permissions checking on every file
you access, etc.  

Even if my collective hd space is larger than the one the original poster was
talking about, the numbers for it seem pretty reasonable for today's computer
users, so I'm taking 200ms as a number that is desirable, rather than one that
was actually gotten on my system.

'time find / > /dev/null' on all of this takes about 3sec after running it once
and probably a minute or so (I didn't really time it) when I haven't run it
recently.  Sure both could be optimised down perhaps as much as an order of
magnitude, but then you have some specialized tool that does really quick inode
walks, not anything particularly useful to the world.  Find is meant to be
useful to the world.  So perhaps it is a performance tradeoff; generality vs
efficiency.

I personally don't think it loses much.  Anyone wanting to quickly get this
sort of information (a complete list of every file on the hd) on a regular
basis should either cache it and update the cache every night or hour or
whatever (a la locate/updatedb), accept the penalty of having your entire
directory structure cached all the time, or wait 10 years and hope that file
counts/fs complexity don't scale up with IO speed.

-kyle

-- 
http://mas.cs.umass.edu/~rawlins
--
Mit diesem Zeichen bann'Ich deinen Zauber!
      (Wagner)

--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9DNddncsSsHSBypARAsOaAKCQkXJNifYaZCuzYo7s4vXKvqF0awCgv4vC
xTIpWLnbYg0hxE6QmwQ61BQvD
-----END PGP SIGNATURE-----

--1yeeQ81UyVL57Vl7--