Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 134481 - tcl/tk applications slow to start
Summary: tcl/tk applications slow to start
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: tk
Version: 3
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
 
Reported: 2004-10-03 21:17 UTC by Gérard Milmeister
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-03 03:34:23 UTC


Attachments (Terms of Use)

Description Gérard Milmeister 2004-10-03 21:17:48 UTC
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 10:22:11 UTC
How do you know it is scanning /usr/share ?

Comment 2 Gérard Milmeister 2004-10-06 16:10:13 UTC
I did an strace.

Comment 3 Jens Petersen 2004-10-15 12:39:39 UTC
Reproduced.


Comment 4 Jens Petersen 2005-03-09 13:03:33 UTC
Do you think this is a Fedora packaging issue?

Comment 5 Gérard Milmeister 2005-03-31 15:27:15 UTC
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 15:45:28 UTC
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-18 02:22:43 UTC
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 08:10:48 UTC
Does this response help at all:

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

?

Comment 10 Gérard Milmeister 2005-09-30 07:53:02 UTC
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 08:12:48 UTC
Ok, so reordering the path does not help?

Comment 12 Gérard Milmeister 2005-09-30 15:12:06 UTC
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.