Thoughts on gitk's memory footprint over linux-2.6.git

In an odd turn of affairs, I am managing a bit of kernel development, and even writing the odd patch myself. As usual, gitk is excellent to visualize what's new in the tree when developers in the team commit and push new stuff.

However, I find it extremely annoying over the kernel tree, due to its memory footprint. It is not the only thing I am running, (Chrome Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and given that I am looking at "just a couple of commits" I don't feel opening a few gitk instances should be problematic... except that it is.

Each gitk instance wants to gobble up >1GB of memory! It really wants to show me the "Linux-2.6.12-rc2(...)Initial git repository build." commit.

Aren't kernel hackers hurting with this? This box blazes through a kernel compile, but only has 2GB RAM. Regardless of amount of RAM, firing up gitk gobbles up >1G and untold CPU cycles.

My tk isn't really up to par, but... here's a stupid idea.

 - In start_rev_list, run git log into a tempfile, and concurrently
open the same file for reading, as fd

 - Read in a bound number of commits, say 10000 ("just" 200MB)

 - If we haven't made it to the end of the file, remember the offset
and keep reading the file, counting matches of /^commit/ to get a
commit count and size the scroll back

 - re-activate the reading as required...

There are of course tricky aspects of concurrent programming at hand. I am not sure what concurrency model gitk has now, but it does a great job of not blocking and not getting confused.

Tricky Tk programming, or go buy some RAM? Yeah, I know.

Now why didn't I pack that Tk book when I moved here?

m