[Etoys-notify] [JIRA] Commented: (SQ-67) duplicate linear slowdown (external name leak)

jira at immuexa.com jira at immuexa.com
Tue Apr 14 17:19:19 EDT 2009

     [ http://tracker.immuexa.com/browse/SQ-67?page=comments#action_34018 ]
Jerome Peace commented on SQ-67:

I like my morphs unique.

If names are not being recycled then why search for a number for them.
Have a ticket roll. One for each morph class or base name.
When a morph wants a unique name give it a ticket number.

No searching. No delay.
And you get each morph with a unique lifetime name.

Easier on the users memory.  

As I use etoys, I am always scratching my head when I look at the names.

"Didn't I just see him over there." 
"Wasn't he smaller." 
"Didn't he have a different color last time?"

Without unique names I gave up trying to solve those mysteries.

Current policy never made sense to me.

> duplicate linear slowdown (external name leak)
> ----------------------------------------------
>          Key: SQ-67
>          URL: http://tracker.immuexa.com/browse/SQ-67
>      Project: squeakland
>         Type: Improvement
>   Components: etoys
>     Reporter: Scott Wallace
>     Priority: Critical
>      Fix For: review

> TRAC ticket 4802 - Morph>>duplicate linear slowdown (external name leak) - Luke Gorrie
> 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.   [HOWEVER -- see the Ahem below...]
> 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.
> (and then later from Luke:  )  Ahem :-)
> The line I really meant is the logical opposite:
>     ((self referencePool at: nameSym ifAbsent: nil) isNil and:
> (yoshiki) etoys 2.2 update 1755 should mitigate the problem.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

More information about the Etoys-notify mailing list