Bug 134481 - tcl/tk applications slow to start
tcl/tk applications slow to start
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: tk (Show other bugs)
3
All Linux
medium Severity low
: ---
: ---
Assigned To: Jens Petersen
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-10-03 17:17 EDT by Gérard Milmeister
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 23:34:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gérard Milmeister 2004-10-03 17:17:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922 Galeon/1.3.17

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):
tk-8.4.5-8

How reproducible:
Always

Steps to Reproduce:
N/A

Additional info:
Comment 1 Jens Petersen 2004-10-06 06:22:11 EDT
How do you know it is scanning /usr/share ?
Comment 2 Gérard Milmeister 2004-10-06 12:10:13 EDT
I did an strace.
Comment 3 Jens Petersen 2004-10-15 08:39:39 EDT
Reproduced.
Comment 4 Jens Petersen 2005-03-09 08:03:33 EST
Do you think this is a Fedora packaging issue?
Comment 5 Gérard Milmeister 2005-03-31 10:27:15 EST
I don't think so. Probably tk (or tcl) scans /usr/share to locate packages, but
this is very inefficient.
Comment 7 Matthew Miller 2005-04-26 11:45:28 EDT
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.
Comment 8 Jens Petersen 2005-05-17 22:22:43 EDT
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

Comment 9 Jens Petersen 2005-09-28 04:10:48 EDT
Does this response help at all:

http://sourceforge.net/mailarchive/message.php?msg_id=11374051

?
Comment 10 Gérard Milmeister 2005-09-30 03:53:02 EDT
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.
Comment 11 Jens Petersen 2005-09-30 04:12:48 EDT
Ok, so reordering the path does not help?
Comment 12 Gérard Milmeister 2005-09-30 11:12:06 EDT
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...

Note You need to log in before you can comment on or make changes to this bug.