Jeff King <peff@xxxxxxxx> writes: > On Wed, Aug 24, 2016 at 02:16:02PM -0700, Junio C Hamano wrote: > >> * jk/pack-objects-optim-mru (2016-08-11) 4 commits >> (merged to 'next' on 2016-08-11 at c0a7dae) >> + pack-objects: use mru list when iterating over packs >> + pack-objects: break delta cycles before delta-search phase >> + sha1_file: make packed_object_info public >> + provide an initializer for "struct object_info" >> >> "git pack-objects" in a repository with many packfiles used to >> spend a lot of time looking for/at objects in them; the accesses to >> the packfiles are now optimized by checking the most-recently-used >> packfile first. >> >> Will hold to see if people scream. > > Just a note that we've been running with this at GitHub on all of our > servers for a bit over a week, and no screaming yet. That's not > necessarily proof of anything, but it does make the audience of "people" > a bit bigger than just "next", as we run quite a few invocations of > pack-objects in a day. > > I don't think that changes anything in the near future, since this is > obviously not for v2.10, but barring any complaints, it's probably a > reasonable topic to consider for the version after (and of course I'll > relay any issues we come across on our servers). Yeah, that "Will hold" is primarily me being lazy [*1*] during the -rc period when updating the "What's cooking". After following the "break delta cycles" patch carefully, I am no longer worried about this topic. It should be in 'master' early in the next cycle, among other topics that are competently done. > I'm planning to deploy the delta-cache topic soon, too, so that should > give it some good exercise. Good. Thanks. [Footnote] *1* ... and a bit more careful, as any "Will merge to 'next'" thing gets marked as "Will merge to 'master'" by default and having any entry under "Will merge to 'master'" in "Meta/cook -w" report tempts me to merge them even during -rc period. -- 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