Linus Torvalds writes: > Well, gitk has certainly had performance problems in the past, they've > been fixable. I think this should just be fixed too. And if the rev-list > is fast enough, then the gitk fix may well be to just not compute the > *whole* history - ie the solution may be as simple as stopping the > background job that does all the graph calculations when it is (pick a > point at random) something like a thousand commits into the graph, and the > user hasn't scrolled down.. I have made a "dev" branch in the gitk.git repository that has some tweaks to the graph layout algorithm which change the appearance a bit; specifically it doesn't continue the graph lines downwards until it has to terminate them with an arrow because the graph is getting too wide. Instead, it always terminates them if they are going to be longer than a certain length (about 100 rows). Also I made some changes to reduce the incidence of two lines having a corner at the same point, for visual clarity. The point of terminating the graph lines early is that it means gitk won't have to lay out the whole graph, just the visible bits and a limited number of rows around that. So I'm interested to know if people think it looks OK visually. (I think it's actually better, myself.) The other thing that takes time is reading in the topology for the previous/next tag computations. I did a patch that wrote out the topology to a cache file but I ran into some problems where the cache includes commits that have gone away since the cache was created. What I need to do to update the cached information is basically the equivalent of git rev-list --all ^root1 ^root2 ... where root1, root2, etc. are the commits in the cache that had no children (and of which all the other commits in the cache are descendents). However, git rev-list will barf if those commits no longer exist. Currently the only solution I can see is to validate them one by one with separate invocations of git rev-list or something (git rev-parse won't do). Would it be possible to make git rev-list ignore commits that don't exist if they have a "^" in front of them, i.e. where we're asking for them to be excluded anyway? If we can do that (or something equivalent) then I can make the cache work reliably. It does speed up gitk enormously, and the cache file is only about 3MB for the kernel tree, so it seems well worth while. Paul. - 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
