Re: [9fans] du and find

[erik quanstrom <quanstro@quanstro.net>]

> i'm not saying it can't be passed in an argument list, just that
> xargs gives you a lazy evaluation of the walk
> of the file tree which can result in a faster result
> when the result is found earlier in the file list.

i have no problem with breadth-first.

my beef with xargs is only that it is used as an excuse
for not fixing exec in unix.  it's also used to bolster the
"that's a rare case" argument.

imho "rare case" arguments work best if the downside
is that the "rare case" is slow or awkward.  in this case
it's broken.

> that's why breadth-first might be useful, by putting
> shallower files earlier in the search results - i often
> do grep foo *.[ch] */*.[ch] */*/*.[ch] to achieve
> a similar result, but you have to guess the depth that way.

clearly i'm not in your league.  my source trees are
smaller than that.  no more than two levels.  or, it
doesn't matter.  on a few machines laying around
the house (details on the poorly-chosen disks here:
http://www.quanstro.net/plan9/fs.html)

i7 2666		0.36u 0.42s 7.35r
Atom 1605	0.83u 1.88s 8.85r
AMD64 2007	0.94u 0.97s 12.51r

and on the fast 10gbe stuff at coraid
Xeon5000 1865 	0.45u 0.83s 4.33r	10gbe myricom
PIV/Xeon 3003 	0.66u 1.41s 7.32r	i82573

(it would be fun to put the i7 with 10gbe
together!)

it's easy to try the completely uncached case at
coraid since the working set is about 7gb and the
cache is only 3.5

Xeon5000 1874 	0.50u 0.84s 27.63r

- erik