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:
Clone Of:
Environment:
Last Closed: 2005-10-03 03:34:23 UTC
Type: ---
Embargoed:


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.