On 12/7/07, Nicolas Pitre <nico@xxxxxxx> wrote: > So the problem seems to be related to the pack access code and not the > repack code. And it must have something to do with the number of deltas > being replayed. And because the repack is attempting delta compression > roughly from newest to oldest, and because old objects are typically in > a deeper delta chain, then this might explain the logarithmic slowdown. What could be wrongly allocating 4GB of memory? Figure that out and you should have your answer. The slow down may be coming from having to search through more and more objects in memory. Memory consumption seem to be correlated to the depth of the delta chain being accessed. It blows up tremendously right at the end. It may even be a square of the length of the chain length. For the normal default case the square didn't hurt, but 250*250 = 62,500 which would eat a huge amount of memory. -- Jon Smirl jonsmirl@xxxxxxxxx - 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
