Thomas Rast <trast@xxxxxxxxxxxxxxx> writes: > Which would be a 4.5% speedup. Obviously that won't quite be > attainable since we want the attributes mechanism to work, but we > still shouldn't have to open 4398 .gitattributes files when there are > only 8 .gitattributes plus one .git/info/attributes. True. At runtime, the attribute mechanism wants a stack of per-directory attributes it can walk up to find the applicable ones maintained for the directory it currently is looking at, and the elements near the leaf are popped from the stack to be discarded when the caller goes on to inspect paths in a different directory (IOW the machinery is optimized for callers that walk the paths in order, without randomly jumping around). But at least within a process like pack-objects that are known to be long lived, we should be able to instead _keep_ the elements that are popped when we leave directories at deeper levels, and bring them back to the stack when the caller asks for a path in that directory later, without going back to the filesystem. -- 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