The following script exposes a performance problem
deleting canvases with many images:
#---
canvas .c
set img [image create photo]
for {set i 0} {$i < 40000} {incr i} { .c create image
10 10 -image $img }
destroy .c
destroy .
#---
Almost all of the time (100 seconds on my system) is
spend in the line "destroy .c", and C-level profiling
with 'callgrind' shows that most of that time is in
tkImage.c:Tk_FreeImage, traversing the linked list of
images.
Tested in 8.4.10 on linux but by inspection of the
source I don't have any reason to believe the
performance has been improved in 8.4.14 or 8.5.
Logged In: YES
user_id=72656
This is by no means a bug. Tk does a "clean" shutdown, as
it is designed to work in embedded systems where you may
finalize and restart it without exiting the system. That
means you need to clean up after the 40K images created.
Logged In: YES
user_id=79902
The problem is probably that the canvas is deleting the
image instances in reverse order to the order in which they
are stored in the linked list of image instances. This
sucks. The question is whether it is going to be worthwhile
*in the normal case* to replace that linked list with some
other storage mechanism (i.e. a hashtable)