gitk performance questions/issues

["David Tweed" <david.tweed@gmail.com>]

Since the gitk is being discussed, I'd like to see if I'm
understanding correctly and hitting problems or just
not doing things correctly. (This is using a
self-compiled "git version 1.5.2.2".)

[Caveat: this is on a repository that is evolves using
my own scripts which mimic the git shell scripts in
calling the low-level programs. I'm 99.999% sure it's
generating a fully valid repo, but I might be missing
something. Actual generating script is at
http://www.personal.rdg.ac.uk/~sis05dst/chronoversion.htm
]

1.  With gitk --all -n 256 on my repo it consistently
takes 12s for the window to appear and 21s for the
"I'm working" cursor to change to a normal cursor.
This is on a dual Xeon machine, /proc/cpuinfo
excerpt

model name      :   Intel(R) Xeon(TM) CPU 3.00GHz
stepping        : 3
cpu MHz         : 2992.496
cache size      : 2048 KB

running x86-64 Fedora 7, packed repo has a 12M
.git dir. Is this the expected start-up time for such a
configuration? The output of
time git-rev-list --parents --topo-order --all>/dev/null
is

real    0m0.048s
user    0m0.044s
sys     0m0.005s

2. Startup time isn't an excessive problem. However,
I often don't seem to be getting the "diff with parent"
being displayed once I click on the another commit. If
I click on several in sequence I get the error
message

"error getting diffs: couldn't fork child process: not enough memory"

The diffs are relatively small (consecutive commits
are generated hourly automatically) and a command
line git-diff generates them instantly.

3. Is "gitk --all -n 256" the best way to say "show me
relatively recent stuff" or should I be using different
options for limiting things?

Many thanks for any insight,

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee