[Pharo-project] Speeding up Pharo 1.1

Igor Stasenko siguctua at gmail.com
Mon Oct 18 18:28:48 EDT 2010


2010/10/19 Levente Uzonyi <leves at elte.hu>:
> 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.

True. Another reason to not register them like MC in Pharo currently does.

> It's inefficient, because someone has to send #finalizeValues, even when
> there's no finalization action.
>
That's why in my patch, i placed #finalizeValues on finishing package
load/unload actions.

>
> 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
> _______________________________________________
> 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.




More information about the Pharo-dev mailing list