> 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
