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

[jira at immuexa.com]

     [ http://tracker.immuexa.com/browse/SQ-67?page=all ]

Scott Wallace updated SQ-67:
----------------------------

    Fix Version: someday
                     (was: triage)

Unless/until we hear any confirmation from those arguing this issue that there is in fact still a problem (after update 1755), we'll lodge this item in "someday".  Jerome, if you can demonstrate an ongoing problem here, please do -- thanks!

> 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: someday

>
>
> 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:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira