{"thread":{"id":"33431","subject":"Poor performance of auto gc","startedAt":"2013-04-08T12:54:58Z","lastAt":"2013-04-08T12:54:58Z","messageCount":1,"participants":["Mark Brown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"213514","messageId":"20130408125458.GM9243@opensource.wolfsonmicro.com","threadId":"33431","inReplyTo":null,"subject":"Poor performance of auto gc","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2013-04-08T12:54:58Z","receivedAt":"2013-04-08T12:54:58Z","isPatch":false,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"I routinely experience very poor behaviour of the auto garbage\ncollection both on the command line and especially with git gui (which\nappears to have a much lower threashold).  I have a kernel git\nrepository I do most of my work in which includes a bunch of trees\nincluding -next and which has some frequently rebased branches.  This\ndoes garbage collection (or for git gui prompts me to do garbage\ncollection) far too frequently.  Previous analysis has shown that the\nissue is that garbage collection leaves a bunch of unreferenced items\nlying around as loose objects rather than in a pack waiting to age out\nof the tree.  This is especially bad towards the end of the release\ncycle when the trees in -next get bigger, right now the gc *always*\ntriggers.\n\nIt seems to me that it should be possible to trigger garbage collection\nbased on proportions of the number of objects in the repository rather\nthan on absolute numbers; some sort of time/object count increase based\nholdoff might be useful to prevent things retriggering too soon.\n"}]}