threads / discuss / 23828

gitk (or tcl/tk) slow to start?

Subject: gitk (or tcl/tk) slow to start?

## tl;dr

4 messages between May 17, 2010 and May 18, 2010.

replies: 3people: 2as markdown or json

Eli Barzilay· May 17, 2010, 10:58 UTC · lore

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?

[This is using a new git version (1.7.1), but it's an old OS (Fedora 7), so maybe tcl/tk is buggy?]

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!
Michael J Gruber· May 17, 2010, 11:51 UTC · re: Eli Barzilay · lore

Re: gitk (or tcl/tk) slow to start?

Eli Barzilay venit, vidit, dixit 17.05.2010 12:58:
Show 12 quoted lines
> 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)?

> [This is using a new git version (1.7.1), but it's an old OS (Fedora
> 7), so maybe tcl/tk is buggy?]
> 
ver += 6 - epsilon ; /* :) */
Michael
Eli Barzilay· May 18, 2010, 02:27 UTC · re: Michael J Gruber · lore

Re: gitk (or tcl/tk) slow to start?

On May 17, Michael J Gruber wrote:
Show 16 quoted lines
> 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!
Michael J Gruber· May 18, 2010, 07:04 UTC · re: Eli Barzilay · lore

Re: gitk (or tcl/tk) slow to start?

Eli Barzilay venit, vidit, dixit 18.05.2010 04:27:
Show 30 quoted lines
> 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...
> 
I guess that was truly wish-ful thinking :)
[You can try and recompile an F12 wish.srpm on F7, of course.]

Sorry, Michael

← back to recent threads