Paul Mackerras <paulus@xxxxxxxxx> writes: > 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). How about terminating them when they are going off-screen? If you worry about reformatting when scrolling, you can terminate them if there will be no change for at least one screen more. More importantly: you can do your layout without having to look at more than two screen's worth of commit data. > 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. Ok, that was what you were already thinking. > So I'm interested to know if people think it looks OK visually. (I > think it's actually better, myself.) I'd think so, too, but will be able to check only later this days. > The other thing that takes time is reading in the topology for the > previous/next tag computations. If you can move that out of the busy loop and do it in the background... > 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. I think it should be possible to come up with a data structure that swallows less memory than the current one. All the info you need are the SHA1s and their relations: the rest can be asked from git while one is scrolling, with a LRU buffer of a few hundred commits for speed. > 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. Cough, cough. If the cache file is only about 3MB, why wouldn't you be able to keep it in memory? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
