Menu

#180 terrible performance deleting canvas with many images

open
5
2006-12-05
2006-05-22
Jeff Epler
No

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.

Discussion

  • Jeff Epler

    Jeff Epler - 2006-05-22
    • labels: --> 104340
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-22

    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.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-05-22
    • labels: 104340 --> 39. Image Basics
    • milestone: 577913 -->
     
  • Donal K. Fellows

    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)

     
  • Donal K. Fellows

    • assigned_to: nobody --> hobbs