Re: Can I have this, pretty please?

Paul Mackerras [off-list ref] writes:

Linus Torvalds writes:

quoted

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