October 2010 - Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

On Mon, Oct 18, 2010 at 1:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Eliot > > > There was a post on this list back in August complaining about Stack > inheriting from LinkedList. There was some discussion, but apparently no > resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core > Image I just downloaded. Rather than reimplementing it to forward to a > contained LinkedList, I think it should use an Array internally like > OrderedCollection does. An Array-based implementation of Stack would be > faster than one based on LinkedList due to the basic stack operations (push, > pop and top) being able to rely more on primitives. This assumes that you > know roughly how a big a stack you need; if you don't, reallocating the > array and copying its contents over and over again will cost you, but this > is an exceptional case;-- most stacks are small and when they aren't, the > programmer usually has enough information to select a reasonable stack size. > > > > *No*. Stack and OrderedCollection differ *usefully*. Adding an item to > a Stack is always O(1). Adding an item to an OrderedCollection is O(N) > because when the array overflows a new one must be allocated and the old > objects copied to the new. Why not apply your speedups to > OrderedCollection, or is that not possible? If not possible, then come up > with a new name and add that. Please /don't/ change Stack. > > I would really like not having Stack inheriting from LinkedList (I hate > subclassing). Now from a VM point of view > is there a constraint that Stack as to be a subclass of LList? > No. The VM doesn't know anything about Stack. > > > > > > > > Enclosed is a fileout of an Array-based Stack implementation. It trounces > the LinkedList-based implementation easily, but more interestingly, it > performs better than an OrderedCollection when used like a stack: > > > > Pushing is roughly ~30% faster: > > r1 :=[100000 timesRepeat: [ > > s := Stack new. > > 10 timesRepeat: [s push: #foo]]] timeToRun. > > r2 := [100000 timesRepeat: [ > > oc := OrderedCollection new. > > 10 timesRepeat: [oc addLast: #foo]]] timeToRun. > > 100 - ((r1 / r2) asFloat * 100). > > > > as is pushing + popping: > > r3 := [100000 timesRepeat: [ > > s := Stack new. > > 10 timesRepeat: [s push: #foo]. > > 10 timesRepeat: [s pop]]] timeToRun. > > r4 := [100000 timesRepeat: [ > > oc := OrderedCollection new. > > 10 timesRepeat: [oc addLast: #foo]. > > 10 timesRepeat: [oc removeLast]]] timeToRun. > > 100 - ((r3 / r4) asFloat * 100). > > _______________________________________________ > > 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 >

Oct. 18, 2010

Re: [Pharo-project] A Lazy Inspector?

by Oscar E A Callau

Thanks Mariano. Now I understand :-) Cheers Ãscar E A Callau On 18 Oct 2010, at 16:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > 2010/10/18 Oscar E A Callau <oalvarez(a)dcc.uchile.cl> > > On Oct 18, 2010, at 14:44 , Mariano Martinez Peck wrote: > >> On Mon, Oct 18, 2010 at 4:40 AM, Oscar E A Callau <oalvarez(a)dcc.uchile.cl> wrote: >> Hello all, >> >> I was wondering what actually the inspector does in the following case: >> >> When you explore (or inspect) the expression: Class environment >> you get all classes in the system dictionary. If you navigate inside a class, for example AColorSelectorMorph, you can see all its properties and one of them is environment, if you go inside it, you get again all classes in the system dictionary. So, you can repeat this infinitely (or until you get run out of memory, I guess) >> >> Is it the behavior of a lazy inspector? If true, why I cannot inspect a mutually-recursive class definition, like this: >> >> Object subclass: #Foo >> instanceVariableNames: 'bar' >> classVariableNames: '' >> poolDictionaries: '' >> category: '' >> >> Foo>>initialize >> bar:= Bar new >> >> Object subclass: #Bar >> instanceVariableNames: 'foo' >> classVariableNames: '' >> poolDictionaries: '' >> category: '' >> >> Foo>>initialize >> bar:= Foo new >> >> here should be foo := Foo new. >> >> Anyway, you should be able to browse these classes without problems. >> The problems is in instance creation. For example, if you evaluate: Foo new. > > Thanks Mariano. May be my question was not well explained. Of course if I evaluate: Foo new, I get into a infinite loop. 1st question, when I'm inspecting, I'm evaluating? > > hehehehe yes :) > Just open a Transcript and inspect: Transcript show: 'welooo' > and you will see 'welooo' in the transcript ;) > > What you actually inspect, is the result of the expression. > > > > In the case that I mention above (Class enviroment) I got all classes in the system and each of them has an environment, that is all classes, and so on. Here, we have a infinite recursion. > > I understand now. > > So, how the inspector get a lazy visualization of the it? > > > I have no idea. But in this case, #environment is a method, not an instVar as your case. > Maybe in the case of the methods, they are only displayed when clicking on it (they just execute the compiledMethod). But this is just a guess. > You should check the class Inspector and NewInspector. > > Cheers > > Mariano > > Greetings > > > > _______________________________________________ > 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 Nicolas Cellier

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

Oct. 18, 2010