On May 17, Michael J Gruber wrote:
> Eli Barzilay venit, vidit, dixit 17.05.2010 12:58:
> > Every time I run gitk when I didn't use it for a while, it takes a
> > long time to start (more than 30 seconds) with no visible cpu load. I
> > tried to strace it, and the result shows that the time is spent
> > stat()ing my whole /usr/lib directory:
> >
> > ...
> > stat("/usr/lib/libelf-0.131.so", {st_mode=S_IFREG|0755, st_size=87496, ...}) = 0
> > stat("/usr/lib/libungif.so.4", {st_mode=S_IFREG|0755, st_size=2444, ...}) = 0
> > stat("/usr/lib/libtiff.so.3.8.2", {st_mode=S_IFREG|0755, st_size=360268, ...}) = 0
> > ...
> >
> > Is this expected? Anything that can be done to avoid it?
>
> I don't expect stat'ing /usr/lib to take 30s. How large is it (file
> size and count)?
I've done some more counting -- the most number of system calls (as
tracked by strace) are 2968 reads, 4582 lstats, and 6520 stats. And
it looks like it's recursively scanning /lib, /usr/lib, and /usr/share
for all *.tcl files. stracing `wish' shows 11000 l/stats -- so I
guess that the problem is there and not in gitk. Trying wish on a
fedora 12 machine, I see only ~350 {,f,l}stat64 calls, and gitk starts
as fast as I'd expect it to.
Oh well, I was hoping that someone knows some bit that needs flipping
or updating to get it to work faster -- I guess it's one more reason
to finally upgrade the F7 machine...
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
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