Re: Can I have this, pretty please?

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 12 Aug 2007, David Kastrup wrote:
> 
> dak@lola:/home/tmp/emacs$ time git-rev-list --parents --topo-order --all>/dev/null
> 
> real    0m9.042s
> user    0m8.801s
> sys     0m0.168s
> 
> This does not even start to _think_ of swapping.

Ok, good. That's the part I care about most. Nine seconds is still a long 
time to wait for the the window to come up, so I'd still suggest at least 
thinking about limiting it, but..

> It does not bother git-rev-list.  What takes them time is that they
> are simply not written with insane amounts of data in mind.

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

Gitk is already incremental (ie it shows the top of the graph long before 
it has drawn it all), so that should not be fundamentally hard. Paul has 
been pretty good about these things when we've had problems in the past.

Paul added to Cc. Paul?

> And newsreaders, for that reason, have a set of strategies for
> limiting the size of the problem (and changing the limits on the fly
> as needed) as well as being efficient with handling it.  They have to
> be _good_ at dealing with that amount of data, or they would have
> fallen by the wayside.

The reason I argue against this is that (a) the graph really is very 
useful. It tells you things that you reasonably visualize any other way. 
And (b) I think what you suggest wouldn't be trivial at all.

But if you want to make a virtual NNTP server that exposes the 
git-rev-list output, go right ahead.

I don't think it should be needed (ie I think we should be able to handle 
this issue other ways), and I don't think it's as good as the alternatives 
(because I don't think any client will ever be able to show the history 
well), but hey, alternatives are fine.

		Linus