Red Hat Bugzilla – Bug 134481
tcl/tk applications slow to start
Last modified: 2007-11-30 17:10:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
tcl/tk applications are slow to start. It probably is caused by the
programs scanning the entire directory /usr/share which has 592
entries on my configuration. The second time a tcl/tk program starts
faster, because of disk buffers, I presume.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
How do you know it is scanning /usr/share ?
I did an strace.
Do you think this is a Fedora packaging issue?
I don't think so. Probably tk (or tcl) scans /usr/share to locate packages, but
this is very inefficient.
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
Seems upstream has been working on this for 8.5, in the meantime:
"RFE 680169 in the Tcl Feature Request Tracker offers a few patches
that are "band-aid" solutions that can be applied to a Tcl 8.4
installation while waiting for the 8.5 release." -- Don Porter
Does this response help at all:
As this response indicates, there is no good way to improve this. IMHO
this has simply been a bad design in tcl. One could patch the source
to exclude /usr/lib and /usr/share from $auto_path, but then some
tcl apps may fail to run, because they expect tcl libraries found
in /usr/lib or /usr/share.
Ok, so reordering the path does not help?
No, since /usr/lib and /usr/share are always included, whatever the
setting of TCLLIBPATH, they are only put at the end of path. But all
directories in the path searched, resp. their subdirectories. I think
this is stupid, but to prevent this will surely break something...