Thomas Rast [off-list ref] 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.