On Fri, Apr 08, 2011 at 03:15:54PM -0400, Jeff King wrote: > > This only checks "does the directory have .git in it?". > > Yeah. I was trying to keep the test as inexpensive as possible, since > this is a very frequently called codepath. But really, doing a more > elaborate test shouldn't matter. The common case will be that the stat > fails, and we do nothing else. > > I do worry about adding an extra lstat for each directory having > noticeable overhead. Maybe it doesn't matter because of the stat > caching, but I didn't measure. I just did some measurements on linux-2.6 (which is a fair bit more directory-heavy than something like git.git). The difference is measurable, but not significant. The average for "git add ." (on a clean, warm-cache repository) over many trials with the extra lstats is about 2-3% slower. But the error margin between trials is something like 3-4%. IOW, even though the average was worse, the best trial for the new code was still faster than the worst trial for the old. This is on Linux, though. It would probably be worse on an OS with a slower stat. -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