On Wed, 19 Mar 2008, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> writes: > > >On Wed, 19 Mar 2008, Junio C Hamano wrote: > > > >> I do not think "very tight" was the reason, but on the other hand, my > >> personal feeling is that 20 was already 10 too many pack idx files we have > >> to walk linearly while looking for objects at runtime. > > > > Since commit f7c22cc68ccb this is no longer such an issue. > > Notice that I did not say "19 too many". I know f7c22cc (always start > looking up objects in the last used pack first, 2007-05-30) was meant to > alleviate the situation, but isn't "no longer" a gross exaggeration? Not at all. Please have a second look at the performance numbers in that commit log, and take into accound the most important metric that I unfortunately failed to mention there (although I subsequently posted it to the list: http://marc.info/?l=git&m=118058197921642&w=2), wich is the time to perform the same operation with a single pack. So you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs. Compare that to 24.9s without that patch. And I still have some further optimizations to implement eventually (http://marc.info/?l=git&m=118062793413099&w=2), but which would probably make a significant difference only in the hundreds-of-packs case anyway. So I really think that the default gc.autopacklimit could be raised. Nicolas -- 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
