[Etoys-notify] #4802 NORM Never A: Morph>>duplicate linear slowdown (external name leak)

[Zarro Boogs per Child]

#4802: Morph>>duplicate linear slowdown (external name leak)
----------------------------+-----------------------------------------------
 Reporter:  lukego          |       Owner:  etoys                            
     Type:  defect          |      Status:  new                              
 Priority:  normal          |   Milestone:  Never Assigned                   
Component:  etoys-activity  |     Version:  Development build as of this date
 Keywords:                  |    Verified:  0                                
----------------------------+-----------------------------------------------
 I have noticed Morph>>duplicate becoming increasingly slow in one of my
 projects. The problem seems to be that the linear search for a suitable
 external name for the new morph (Sketch1, Sketch2, ...) becomes longer
 every time because old names are not reused even after their morphs have
 been removed (with either 'owner removeAllMorphs' or 'owner submorphs do:
 [:m | m delete]').

 I found that I had over 20,000 registered names with stem Sketch, because
 I've been calling duplicate very often on SketchMorphs. The sketches are
 not in the world at the same time -- the names are leaking.

 Running 'TimeProfileBrowser onBlock: [mySketch duplicate]' shows the time
 being spent in PasteUpMorph>>uniqueNameForReferenceFor:. Digging with the
 inspector reveals that 'World referencePool' includes very many keys
 'Sketch<num>' with value nil. I presume that these are names that were
 used by morphs that have since been garbage collected. This bit of code in
 PasteUpMorph>>uniqueNameForReferenceFor: chooses to mint new names instead
 of reusing nil-valued ones:

         aName _ Utilities keyLike: stem satisfying:
                 [:jinaLake |
                         nameSym _ jinaLake asSymbol.
 "***"                    ((self referencePool includesKey: nameSym) not
 and:
                                 [(Smalltalk includesKey: nameSym) not])
 and:
                                                 [(knownClassVars includes:
 nameSym) not]].

 I have experimented with modifying this method so that nil-valued names
 can be reused, replacing the line marked "***" with:

                          ((self referencePool at: nameSym ifAbsent: nil)
 ~= nil and:

 and I have verified that this solved the specific performance problem by
 causing low-numbered names to be reused.

 I don't understand the invariants around the 'World referencePool' data
 structure so I don't know if this is a correct fix or not so I humbly
 leave the patch for your consideration.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4802>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system