- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 18.10.2010 23:21, Igor Stasenko wrote: > 2010/10/19 Levente Uzonyi<leves(a)elte.hu>: >> On Mon, 18 Oct 2010, Nicolas Cellier wrote: >> >>> 2010/10/18 Igor Stasenko<siguctua(a)gmail.com>: >>>> On 18 October 2010 23:18, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> 2010/10/17 Levente Uzonyi<leves(a)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) Cheers, Henry

Oct. 18, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Levente Uzonyi

On Mon, 18 Oct 2010, Igor Stasenko wrote: > Stephane, i could say more: > - i don't like how LinkedList implemented. > > I don't see why it should mimic things like #at: #at:put: at all.. It's not mimicing those methods. A list usually support things like this, but the user should know the consequences. > IMO this protocol should be pruned from it, to not provoke uses which > completely do not fit for given data structure. I'm not sure if it's okay to remove features, because users lacking really basic CS knowledge may use them the wrong way. > > Removing/inserting into the middle of list is quite ineffective > operation (O(n)), As long as you don't give away the link objects, it's O(n), otherwise it can be O(1). > while inserting at the begginning/end of list is O(1). > > Lists are sequenceable.. but sequenceable ~~ indexable. Period. Sequenceable is indexable, but good performance is not guaranteed. Levente > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

2010/10/19 Levente Uzonyi <leves(a)elte.hu>: > On Mon, 18 Oct 2010, Nicolas Cellier wrote: > >> 2010/10/18 Igor Stasenko <siguctua(a)gmail.com>: >>> >>> On 18 October 2010 23:18, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> 2010/10/17 Levente Uzonyi <leves(a)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? > > Levente > >> >> Nicolas >> >>>> (WeakRegistry->0). >>>> (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} >>>> >>>> I tried to inspect it 5 minutes ago, but hey, answer in another email... >>>> Ah, OK, cmd+shift+. just worked. I had to interrupt >>>> #finalizationProcess itself finally... >>>> Oh inspect is sorting the keys... unusable. >>>> So what's in the array ? Things like >>>> >>>> (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a >>>> MCMethodDefinition(ScriptLoader>>update12125) >>>> (PragmaCollector>>#release "a CompiledMethod(964689920)")->a >>>> MCMethodDefinition(PragmaCollector>>release) >>>> (Float>>#arcSin "a CompiledMethod(358088704)")->a >>>> MCMethodDefinition(Float>>arcSin) >>>> >>>> I don't understand yet, but I begin to gather clues why updating pharo >>>> goes so badly... >>>> >>>> Nicolas >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)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(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Mon, 18 Oct 2010, Nicolas Cellier wrote: > 2010/10/18 Igor Stasenko <siguctua(a)gmail.com>: >> On 18 October 2010 23:18, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/10/17 Levente Uzonyi <leves(a)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. Levente > > Nicolas > >>> (WeakRegistry->0). >>> (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} >>> >>> I tried to inspect it 5 minutes ago, but hey, answer in another email... >>> Ah, OK, cmd+shift+. just worked. I had to interrupt >>> #finalizationProcess itself finally... >>> Oh inspect is sorting the keys... unusable. >>> So what's in the array ? Things like >>> >>> (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a >>> MCMethodDefinition(ScriptLoader>>update12125) >>> (PragmaCollector>>#release "a CompiledMethod(964689920)")->a >>> MCMethodDefinition(PragmaCollector>>release) >>> (Float>>#arcSin "a CompiledMethod(358088704)")->a >>> MCMethodDefinition(Float>>arcSin) >>> >>> I don't understand yet, but I begin to gather clues why updating pharo >>> goes so badly... >>> >>> Nicolas >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Mon, 18 Oct 2010, Nicolas Cellier wrote: > 2010/10/17 Levente Uzonyi <leves(a)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). (WeakRegistry->0). > (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} > > I tried to inspect it 5 minutes ago, but hey, answer in another email... > Ah, OK, cmd+shift+. just worked. I had to interrupt > #finalizationProcess itself finally... > Oh inspect is sorting the keys... unusable. > So what's in the array ? Things like > > (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a > MCMethodDefinition(ScriptLoader>>update12125) > (PragmaCollector>>#release "a CompiledMethod(964689920)")->a > MCMethodDefinition(PragmaCollector>>release) > (Float>>#arcSin "a CompiledMethod(358088704)")->a > MCMethodDefinition(Float>>arcSin) > > I don't understand yet, but I begin to gather clues why updating pharo > goes so badly... IIRC Igor already checked that most of the time is spend in the finalization process and gc. Levente > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

On 18 October 2010 23:41, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/10/18 Igor Stasenko <siguctua(a)gmail.com>: >> On 18 October 2010 23:18, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/10/17 Levente Uzonyi <leves(a)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. > I disagree. Its not a simplification. Its a bug fix! :) Recently, i provided the similar thing for Pharo (didn't knew it was already fixed for Squeak): http://code.google.com/p/pharo/issues/detail?id=3048 > Nicolas > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Igor Stasenko

Stephane, i could say more: - i don't like how LinkedList implemented. I don't see why it should mimic things like #at: #at:put: at all.. IMO this protocol should be pruned from it, to not provoke uses which completely do not fit for given data structure. Removing/inserting into the middle of list is quite ineffective operation (O(n)), while inserting at the begginning/end of list is O(1). Lists are sequenceable.. but sequenceable ~~ indexable. Period. -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Nicolas Cellier

2010/10/18 Igor Stasenko <siguctua(a)gmail.com>: > On 18 October 2010 23:18, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2010/10/17 Levente Uzonyi <leves(a)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. Nicolas >> (WeakRegistry->0). >> (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} >> >> I tried to inspect it 5 minutes ago, but hey, answer in another email... >> Ah, OK, cmd+shift+. just worked. I had to interrupt >> #finalizationProcess itself finally... >> Oh inspect is sorting the keys... unusable. >> So what's in the array ? Things like >> >> (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a >> MCMethodDefinition(ScriptLoader>>update12125) >> (PragmaCollector>>#release "a CompiledMethod(964689920)")->a >> MCMethodDefinition(PragmaCollector>>release) >> (Float>>#arcSin "a CompiledMethod(358088704)")->a >> MCMethodDefinition(Float>>arcSin) >> >> I don't understand yet, but I begin to gather clues why updating pharo >> goes so badly... >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 18, 2010

Re: [Pharo-project] Some questions about pharo

by Alexander LazareviÄ

2010/10/18 Adrien BARREAU <abarreau.dev(a)live.fr>: > - If I run a headless Pharo, is it possible to display the graphical > interface after? (for example, if something raises an exception, I want to > open the GUI and use the debugger) It depends. If your headless Pharo image is running on a unix VM you could utilize the genius OSProcess/XDisplayControl plugin available for this VM. Load the appropriate packages from [1] into your Pharo image and then you can close and reopen the window even on another machine if it's running X11. For example this OSProcess thisOSProcess closeXDisplay. (Delay forSeconds: 5) wait. OSProcess thisOSProcess displayOnXServer: ':0.0'. will close the Window (headless) and reopen it (headful) again on the local X server after five seconds. If you're using Seaside in that image you could trigger window open/close via Seaside or you could change the default handler for errors to make the window open on the local display as a default, ... Alex [1] http://www.squeaksource.com/OSProcess

Oct. 18, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

On 18 October 2010 23:18, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2010/10/17 Levente Uzonyi <leves(a)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. > (WeakRegistry->0). > (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} > > I tried to inspect it 5 minutes ago, but hey, answer in another email... > Ah, OK, cmd+shift+. just worked. I had to interrupt > #finalizationProcess itself finally... > Oh inspect is sorting the keys... unusable. > So what's in the array ? Things like > > (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a > MCMethodDefinition(ScriptLoader>>update12125) > (PragmaCollector>>#release "a CompiledMethod(964689920)")->a > MCMethodDefinition(PragmaCollector>>release) > (Float>>#arcSin "a CompiledMethod(358088704)")->a > MCMethodDefinition(Float>>arcSin) > > I don't understand yet, but I begin to gather clues why updating pharo > goes so badly... > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 18, 2010