[Pharo-project] Speeding up Pharo 1.1

Levente Uzonyi leves at elte.hu
Mon Oct 18 17:51:19 EDT 2010


On Tue, 19 Oct 2010, Igor Stasenko wrote:

> On 19 October 2010 00:30, Henrik Sperre Johansen
<henrik.s.johansen at veloxit.no> wrote:
>  On 18.10.2010 23:21, Igor Stasenko wrote:
>>
>> 2010/10/19 Levente Uzonyi<leves at elte.hu>:
>>>
>>> On Mon, 18 Oct 2010, Nicolas Cellier wrote:
>>>
>>>> 2010/10/18 Igor Stasenko<siguctua at gmail.com>:
>>>>>
>>>>> On 18 October 2010 23:18, Nicolas Cellier
>>>>> <nicolas.cellier.aka.nice at gmail.com>  wrote:
>>>>>>
>>>>>> 2010/10/17 Levente Uzonyi<leves at elte.hu>:
>>>>>>>
>>>>>>> On Sat, 16 Oct 2010, Bart Veenstra wrote:
>>>>>>>
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I have been working with Pharo for almost a month now, and I suspect
>>>>>>>> that the performance is degrading fast. UI tasks takes several
>>>>>>>> seconds
>>>>>>>> to react to my keyboard.
>>>>>>>
>>>>>>> That kind of sluggishness is probably related to finalization/gc.
>>>>>>> Please
>>>>>>> send us the result of the following expression:
>>>>>>>
>>>>>>> (WeakArray classPool at: #FinalizationDependents)
>>>>>>>        select: [ :each | each notNil ]
>>>>>>>        thenCollect: [ :each | each class ->  each size ]
>>>>>>>
>>>>>> While updating pharo 1.2, after an EndOfCentralDirectory error, I got
>>>>>> a very unresponsive image...
>>>>>>
>>>>>> ((WeakArray classPool at: #FinalizationDependents) as: Array)
>>>>>>       select: [ :each | each notNil ]
>>>>>>       thenCollect: [ :each | each class ->  each size]
>>>>>> ->
>>>>>> {(WeakIdentityKeyDictionary->22370).
>>>>>
>>>>> This is an MC cache. And major reason of image slowdown.
>>>>>
>>>> Levente did this simplification in trunk:
>>>>
>>>> cachedDefinitions
>>>>        ^definitions ifNil: [ definitions := WeakIdentityKeyDictionary
>>>> new
>>>> ]
>>>>
>>>> It would be worth a try in Pharo.
>>>
>>> IIRC Pharo's WeakKeyDictionary (and subclasses) don't work properly if
>>> they're not registered to the finalization process. So this won't work as
>>> long as that's not fixed.
>>>
>> Huh? Can you provide a code to show it? Test case please?
>>
> Just add lots of objects which will be GC'd to an unregistered
> WeakKeyDictionary.
> After X objects are gc'd, you'd still have X nil-keyed associations in the
> dictionary.
> Add Y objects, gc those, and you have X+Y nil-keys in the dict.
> (If dict grown/rehashed, all nicely placed index 1 onwards)
>

it doesn't sounds like incorrect behavior (i.e. pruning a nil-ed keys
before #finalizeValues could visit them).


It's incorrect, because WeakKeyDictionaries are not designed to be 
accessed concurrently, but this can happen if the dictionary is 
registered to the finalization process.
It's inefficient, because someone has to send #finalizeValues, even when 
there's no finalization action.


Levente


> Cheers,
> Henry
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


More information about the Pharo-dev mailing list