Re: gitk performance questions/issues
- From
- David Tweed <david.tweed@gmail.com>
- Date
- Aug 13, 2007, 17:18 UTC
- Message-ID
- <e1dab3980708131018h495c5cf2m76cb8f6ffc4df6dc@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.0.999.0708130945420.30176@woody.linux-foundation.org>
On 8/13/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 8 quoted lines
> Alternatively, maybe your repo has some odd structure (do you have tons > and tons of branches or tags?) and "gitk" ends up having some problem with > that. What does > > git rev-parse --all | wc -l > > say? Various git tools have had performance problems with thousands of > branches or tags in the past.
Ah, that's it: I've got $ wc .git/packed-refs 1915 3832 130178 .git/packed-refs and 35 currently unpacked tags and temporarily moving that file away, gitk now starts up virtually instantly. My usage generates a tag per commit which is probably excessive. For completeness, $ git rev-parse --all | wc -l 1957
Thinking about it, I suppose even if you're only looking at the last 256 commits you've got to look through all the tags to see whether or not they refer to something within that window, so it's not unreasonable for it to affect startup time.
The bit that is a quite surprising to me is that once the window has finished initialising, clicking on one of the blue dots now (ie without .git/packed-refs file) now generates the diffs instantly as well. It's not obvious to me why the existence/non-existence of tags should affect displaying-diff performance.
Anyway, now I know I can rearrange things not to need anything like as many tags.
Many thanks for the help,
-- cheers, dave tweed__________________________ david.tweed@gmail.com Rm 124, School of Systems Engineering, University of Reading. "we had no idea that when we added templates we were adding a Turing- complete compile-time language." -- C++ standardisation committee