Bug 134481

Summary:	tcl/tk applications slow to start
Product:	[Fedora] Fedora	Reporter:	Gérard Milmeister <gemi>
Component:	tk	Assignee:	Jens Petersen <petersen>
Status:	CLOSED CANTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	medium
Version:	3	CC:	mattdm
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-03 03:34:23 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	150221

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...