Nicolas Pitre wrote:
Another way to achieve that is to place objects that are accessed together
nearby, and issue a larger read so as to bring them into cache. I imagine
that placing commit objects and associated tree and blobs in history order
should help here (but maybe git already does that, I'm not familiar with the
internals).
GIT already does that indeed, except for commit objects which are all
together for better performances on history traversal operations.
After a fresh repack, the checkout of the latest revision should produce
a nearly perfect linear and contigous access into the early portion of
the same pack. Things will get more random with access to objects
further back in history of course, but those objects are less likely to
be accessed as often.
Thanks. Actually I should have deduced this from the speed of 'git log' ;-)
--
error compiling committee.c: too many arguments to function
-
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
