{"thread":{"id":"8991","subject":"'git log FILE' slow","startedAt":"2007-07-11T20:33:41Z","lastAt":"2007-07-11T21:03:07Z","messageCount":2,"participants":["Yakov Lerner","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47070","messageId":"f36b08ee0707111333q38004cb5x152f25e2055e2796@mail.gmail.com","threadId":"8991","inReplyTo":null,"subject":"'git log FILE' slow","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2007-07-11T20:33:41Z","receivedAt":"2007-07-11T20:33:41Z","isPatch":false,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"[git version 1.5.1.3]\n\n'git-log FILE' takes 10-13 sec.  What can I do to identify\nthe reason ? 'git log >/dev/null' takes 0.1 sec (cached).\nOn the cloned copy, the times are approximately same.\n\nThe 'git-count-objects -v' shows:\n\ncount: 9830\nsize: 241412\nin-pack: 12080\npacks: 18\nprune-packable: 188\ngarbage: 0\n\nThe strace shows only thousands of sbrk during the 10-13 sec time\n(after some initial I/O). Ltrace, I was not able to complete, takes too much.\n\nYakov\n"},{"id":"47073","messageId":"alpine.LFD.0.999.0707111354150.20061@woody.linux-foundation.org","threadId":"8991","inReplyTo":"f36b08ee0707111333q38004cb5x152f25e2055e2796@mail.gmail.com","subject":"Re: 'git log FILE' slow","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-11T21:03:07Z","receivedAt":"2007-07-11T21:03:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 11 Jul 2007, Yakov Lerner wrote:\n> \n> 'git-log FILE' takes 10-13 sec.  What can I do to identify\n> the reason ? 'git log >/dev/null' takes 0.1 sec (cached).\n\n\"git log FILE\" is simply *fundamnentally* much more expensive than \"git \nlog\".\n\nThere's nothing to \"identify\". Both go through the whole log of the \nproject, but \"git log file\" has to look at every tree, and see where the \nfile actually changed.\n\nHowever, \"fundmanetally more expensive\" doesn't actually mean that it \nshould be that slow. I suspect that your archive is not packed, so you \nhave probably thousands of individual objects in the filesystem, and are \nslowing down your git usage totally needlessly.\n\nSo do\n\n\tgit gc\n\non the archive, and you'll probably be happy.\n\nThat said, 10-13 seconds *can* be valid for a really big archive, ie \nthat's the kinds of times you might eventually expect for something like \nthe full KDE archive (if they don't split the subprojects up).\n\nI doubt that's it.\n\n> On the cloned copy, the times are approximately same.\n\nThis is a big clue. Cloning will generate a new pack.\n\n> The 'git-count-objects -v' shows:\n> \n> count: 9830\n> size: 241412\n> in-pack: 12080\n> packs: 18\n> prune-packable: 188\n> garbage: 0\n\nTons of packs, and lots of unpacked objects.\n\nJust get used to doing \"git gc\" once a week (or maybe once a month - I \nguess you've not done it at all?)\n\n> The strace shows only thousands of sbrk during the 10-13 sec time\n> (after some initial I/O). Ltrace, I was not able to complete, takes too much.\n\nHmm. I'd have expected to see some \"stat()/open()\" calls if it was really \njust about packing, so I'm a bit surprised, but I really do think you \nshould just garbage collect your packs. Having 12k objects in 18 packs is \nridiculous - each pack must be pitifully small.\n\nHere's my kernel archive:\n\n\t[torvalds@woody linux]$ git count-objects -v\n\tcount: 364\n\tsize: 2328\n\tin-pack: 506495\n\tpacks: 12\n\tprune-packable: 5\n\tgarbage: 0\n\nie I have forty times the objects, in fewer packs than you do (and most of \nit is in one big one). After a \"git gc\", it looks like\n\n\t[torvalds@woody linux]$ git count-objects -v\n\tcount: 0\n\tsize: 0\n\tin-pack: 506090\n\tpacks: 1\n\tprune-packable: 0\n\tgarbage: 0\n\nand everything is happier (not that it was unhappy before either, but \nmine was much better packed than yours was).\n\n\t\tLinus\n"}]}