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