On Mon, 13 Aug 2007, David Tweed wrote: > > 1. With gitk --all -n 256 on my repo it consistently > takes 12s for the window to appear and 21s for the > "I'm working" cursor to change to a normal cursor. There is something seriously wrong there. For me, on the kernel archive (which is much bigger than yours), the window appears immediately, and the "working cursor" takes about two seconds to disappear. > This is on a dual Xeon machine, /proc/cpuinfo > excerpt > > model name : Intel(R) Xeon(TM) CPU 3.00GHz > stepping : 3 > cpu MHz : 2992.496 > cache size : 2048 KB Your CPU is fast enough.. > running x86-64 Fedora 7, packed repo has a 12M > .git dir. .. and you're apparently fully packed, and do not even have all that big a repository. So: > Is this the expected start-up time for such a > configuration? Absolutely not. > The output of > > time git-rev-list --parents --topo-order --all>/dev/null > > is > > real 0m0.048s > user 0m0.044s > sys 0m0.005s Ok, so it's not the revision generation that takes time. > 2. Startup time isn't an excessive problem. However, > I often don't seem to be getting the "diff with parent" > being displayed once I click on the another commit. If > I click on several in sequence I get the error > message > > "error getting diffs: couldn't fork child process: not enough memory" You have some *serious* problem somewhere. I think your tcl/tk is screwed up somehow. 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. One thing to try: I think that "git gc" back in the 1.5.2.2 days didn't pack branches by default - and if you have lots and lots of branches, you should try to make sure that they are packed, using git pack-refs --all --prune (newer git versions will do this automatically in "git gc" - while v1.5.2.2 will only pack the tags by default, iirc). > The diffs are relatively small (consecutive commits > are generated hourly automatically) and a command > line git-diff generates them instantly. Yeah, it sounds like git itself has no problems, and it's literally gitk that shows some strange behaviour. > 3. Is "gitk --all -n 256" the best way to say "show me > relatively recent stuff" or should I be using different > options for limiting things? That's a perfectly good thing to do. You don't need the "-n", you can just do "-256". That said, if you actually want commits to be in date order, use gitk -d --all -256 instead, which tells gitk to use "--date-order" instead, which is often nicer (the graph ends up being a bit messier, but it gives you a more correct view of relative dates when you have multiple branches! Linus - 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
