Re: Can I have this, pretty please?

From: David Kastrup <dak@gnu.org>
Date: Aug 13, 2007, 05:49 UTC
Message-ID: <85wsw03rxk.fsf@lola.goethe.zz>
In-Reply-To: <18111.42072.605823.932110@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> writes:

Show 16 quoted lines

> 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.

Show 6 quoted lines

> 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.

Show 6 quoted lines

> 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