Uwe Kleine-König <ukleinek@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes: > David Kastrup wrote: >> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: >> > On Sun, 12 Aug 2007, Linus Torvalds wrote: >> >> >> >> A newsreader is mis-designed for all the same reasons SVN is misdesigned: >> >> it sees the messages (commits) as a _tree_. >> > >> > Side note: the lack of this bug is what makes showing large >> > histories graphically be expensive in the first place. >> >> Not really. >> >> 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. > rev-list doesn't try to draw a line from each commit to its parents. Well, that's what --topo-order is somewhat about, but it might actually not do much together with --all. > That's the really intensive part. So when gitk reads > > d56871cb0e6ceeca8e5435ff95409d78bed014f0 a046fe0cb8697bc97993b2e609688ff5e89e3e9 > > it must remember this line at least until it sees a line starting with > a046fe0cb8697bc97993b2e609688ff5e89e3e9. 20 bytes of payload for a commit number. Make a usable hashing data structure for it, adds perhaps another 20 bytes. Links to all parents are 4 bytes each. All in all, we won't need more than 64 bytes per commit. Take 100000 of them, and you are at 6.4MB. And that is not taking into account that you can let git-name-rev cut the information retrieval down much much more, and just get the rest of the information when it is actually moved on-screen. I don't actually _want_ to see 50 parallel lines from bottom to top of screen obscuring my branch display and taking away all the screen estate: that is completely useless information. Pack the branches away into a cable pipe and let them come out isolated again only when they are actually involved on the screen. There is no necessity to prerender/layout 50 yards of graphing. -- 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
