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
--
martin.langhoff@xxxxxxxxx
martin@xxxxxxxxxx -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
--
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