On Fri, Oct 03, 2014 at 03:19:29PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Prune has to walk $GIT_DIR/objects/?? in order to find the > > set of loose objects to prune. Other parts of the code > > (e.g., count-objects) want to do the same. Let's factor it > > out into a reusable for_each-style function. > > Doesn't fsck also look at these as well? I recall that we also have > a "sort by inum" trick employed there. Would it also be applicable > to these two callers? I didn't think to check fsck. It does have a similar function and could be converted. Fsck does store the inode and later visits the files in inode order. I don't know if it matters as much here, because we are not opening most of the files, just stat()ing them. I'd also be kind of surprised if this optimization really matters in practice these days. The inode-sorting comes from 7e8c174 (fsck-cache: sort entries by inode number, 2005-05-02). That predates packfiles by several months, I believe, and you are not likely to have a very large number of loose objects anymore (and if you do, you will get _way_ better performance simply by packing). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html