December 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Wrong number with message tally?

by Nicolas Cellier

I did not check code, but to me, the symptoms look like the other processes are not reported but their are still counted in the percentage. You can compare the results of these two invocations: MessageTally spyOn: [1 to: 10000 do: [:i | Float pi storeString]]. - 386 tallies, 389 msec. **Tree** -------------------------------- Process: (40s) 328990720: nil -------------------------------- 61.4% {239ms} Float>>storeOn: 61.4% {239ms} Float>>storeOn:base: 61.4% {239ms} Float>>absPrintExactlyOn:base: snip... MessageTally spyAllOn: [1 to: 10000 do: [:i | Float pi storeString]]. - 386 tallies, 388 msec. **Tree** -------------------------------- Process: other processes -------------------------------- -------------------------------- Process: (40s) 328990720: nil -------------------------------- 58.5% {227ms} Float>>storeOn: 58.5% {227ms} Float>>storeOn:base: 57.5% {223ms} Float>>absPrintExactlyOn:base: snip... -------------------------------- Process: (50) 240123904: WeakArray class>>finalizationProcess -------------------------------- 2.6% {10ms} WeakArray class>>finalizationProcess -------------------------------- Process: (60) Input events fetching process: [delaySemaphore wait] in Delay>>wait -------------------------------- 36.3% {141ms} InputEventPollingFetcher(InputEventFetcher)>>eventLoop 36.3% {141ms} InputEventPollingFetcher>>waitForInput 36.3% {141ms} Delay>>wait Strangely in Squeak, spyOn: often reports about the finalizationProcess - 381 tallies, 381 msec. **Tree** -------------------------------- Process: other processes -------------------------------- 7.6% {29ms} WeakArray class>>finalizationProcess -------------------------------- Process: (40s) 93165: nil -------------------------------- 86.4% {329ms} Float>>storeOn: |86.4% {329ms} Float>>storeOn:base: | 85.8% {327ms} Float>>absPrintExactlyOn:base: | 41.5% {158ms} False>>| snip... Nicolas 2011/12/24 Alexandre Bergel <alexandre.bergel(a)me.com>: > I am not familiar with CUIS. But MessageTally is implemented in just one class. I commented it and some added tests a few months ago. > > In Visualworks, the root of the callgraph is always reported at 100%. > > I will continue to work on the Pharo version. > > Alexandre > > > On 24 Dec 2011, at 11:52, StÃ©phane Ducasse wrote: > >> Alex >> >> normally I integrated the fixes of juan long time ago. Now could you have a look at CUIS to see if you get the same effect. >> >> Stef >> >> On Dec 24, 2011, at 3:29 PM, Alexandre Bergel wrote: >> >>>> This means that some other process (probably the finalization process, since #factorial creates a lot of garbage) was running and/or gc happened during the "missing" 34.2%. The gc times are listed below. >>> >>> I also thought about that. But I doubt this is the only reason. I tried: >>> >>> MessageTally spyOn: [ Â 100 timesRepeat: [XMLDOMParser parse: (FileStream fileNamed: 'path to an xml file') contents ]]. >>> >>> and I obtain >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> - 168 tallies, 168 msec. >>> >>> **Tree** >>> -------------------------------- >>> Process: (40s) Â 754188288: nil >>> -------------------------------- >>> 18.5% {31ms} XMLDOMParser>>parseDocument >>> 18.5% {31ms} XMLDOMParser(SAXHandler)>>parseDocument >>> Â 18.5% {31ms} XMLParser>>parseDocument >>> Â Â 18.5% {31ms} XMLParser>>parseToken >>> Â Â Â 18.5% {31ms} XMLTokenizer>>nextToken >>> Â Â Â Â 16.1% {27ms} XMLTokenizer>>nextMarkupToken >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> The memory stat are >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> **Memory** >>> Â Â Â old Â Â Â Â Â Â Â Â Â Â +120,524 bytes >>> Â Â Â young Â Â Â Â Â -442,960 bytes >>> Â Â Â used Â Â Â Â Â Â -322,436 bytes >>> Â Â Â free Â Â Â Â Â Â +322,436 bytes >>> >>> **GCs** >>> Â Â Â full Â Â Â Â Â Â Â Â Â Â 0 totalling 0ms (0.0% uptime) >>> Â Â Â incr Â Â Â Â Â Â 12 totalling 5ms (3.0% uptime), avg 0.0ms >>> Â Â Â tenures Â Â Â Â 2 (avg 6 GCs/tenure) >>> Â Â Â root table Â Â Â 0 overflows >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> >>> The factorial example consumes more memory, and it is reported to consume 72% >>> >>> Something is weird. I will look into it. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel Â http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 24, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by Nicolas Cellier

Oh, but I didn't understand it was about optimization... Good practice is to not optimize prematurely ;) For example, inlining some message send, replacing explicit iteration message by more obscure to:do: or whileTrue: loops etc... are not good practices, just compromises... Nicolas 2011/12/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Bad practices and anti-pattern might be very instructive too... > > Nicolas > > 2011/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: >> >>> Not sure what you mean with good coding practice, but here my contrib: >>> >>> - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) >>> - symbol polymorphic to block and other object-as-function >> >> Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. >> >>> - writing test before fixing code >>> - having short methods >> indeed >> >> Here is what I started to write. >>

Dec. 24, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by StÃ©phane Ducasse

Yes this is what I wrote in the 4 pages so far :) Stef On Dec 24, 2011, at 4:18 PM, Nicolas Cellier wrote: > Bad practices and anti-pattern might be very instructive too... > > Nicolas > > 2011/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: >> >>> Not sure what you mean with good coding practice, but here my contrib: >>> >>> - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) >>> - symbol polymorphic to block and other object-as-function >> >> Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. >> >>> - writing test before fixing code >>> - having short methods >> indeed >> >> Here is what I started to write. >> >

Dec. 24, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by Nicolas Cellier

Bad practices and anti-pattern might be very instructive too... Nicolas 2011/12/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: > >> Not sure what you mean with good coding practice, but here my contrib: >> >> - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) >> - symbol polymorphic to block and other object-as-function > > Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. > >> - writing test before fixing code >> - having short methods > indeed > > Here is what I started to write. >

Dec. 24, 2011

[Pharo-project] [update 1.4] #14265

by StÃ©phane Ducasse

- Issue 5124: Chronology Printing/Accessing Efficiency Improvements. Thanks Sven van Caekenberghe. http://code.google.com/p/pharo/issues/detail?id=5124 - Issue 5067: Make package cache location changeable (first part). Thanks Mariano Martinez-Peck. http://code.google.com/p/pharo/issues/detail?id=5067. - Issue 4866: NonInteractiveTranscript Thanks Sven van Caekenberghe. http://code.google.com/p/pharo/issues/detail?id=4866 Stef

Dec. 24, 2011

[Pharo-project] PBE2 - Draft chapters for review

by jannik.laval

Hi list, As you probably know, the Pharo By Example 2 is in progress. Some chapters will be finished soon. And we hope to provide the whole book in 2012. So, for Chrismas, we provide you some chapters, that you can review. Feel free to send us comments if you have any. The new page is temporarily available here: http://rmod.lille.inria.fr/pbe2/. It currently has the layout of the previous book but will be changed soon. Merry Chrismas ! Jannik

Dec. 24, 2011

Re: [Pharo-project] Wrong number with message tally?

by Alexandre Bergel

I am not familiar with CUIS. But MessageTally is implemented in just one class. I commented it and some added tests a few months ago. In Visualworks, the root of the callgraph is always reported at 100%. I will continue to work on the Pharo version. Alexandre On 24 Dec 2011, at 11:52, StÃ©phane Ducasse wrote: > Alex > > normally I integrated the fixes of juan long time ago. Now could you have a look at CUIS to see if you get the same effect. > > Stef > > On Dec 24, 2011, at 3:29 PM, Alexandre Bergel wrote: > >>> This means that some other process (probably the finalization process, since #factorial creates a lot of garbage) was running and/or gc happened during the "missing" 34.2%. The gc times are listed below. >> >> I also thought about that. But I doubt this is the only reason. I tried: >> >> MessageTally spyOn: [ 100 timesRepeat: [XMLDOMParser parse: (FileStream fileNamed: 'path to an xml file') contents ]]. >> >> and I obtain >> -=-=-=-=-=-=-=-=-=-=-=-= >> - 168 tallies, 168 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) 754188288: nil >> -------------------------------- >> 18.5% {31ms} XMLDOMParser>>parseDocument >> 18.5% {31ms} XMLDOMParser(SAXHandler)>>parseDocument >> 18.5% {31ms} XMLParser>>parseDocument >> 18.5% {31ms} XMLParser>>parseToken >> 18.5% {31ms} XMLTokenizer>>nextToken >> 16.1% {27ms} XMLTokenizer>>nextMarkupToken >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> The memory stat are >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> **Memory** >> old +120,524 bytes >> young -442,960 bytes >> used -322,436 bytes >> free +322,436 bytes >> >> **GCs** >> full 0 totalling 0ms (0.0% uptime) >> incr 12 totalling 5ms (3.0% uptime), avg 0.0ms >> tenures 2 (avg 6 GCs/tenure) >> root table 0 overflows >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> >> The factorial example consumes more memory, and it is reported to consume 72% >> >> Something is weird. I will look into it. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2011

Re: [Pharo-project] Wrong number with message tally?

by StÃ©phane Ducasse

Alex normally I integrated the fixes of juan long time ago. Now could you have a look at CUIS to see if you get the same effect. Stef On Dec 24, 2011, at 3:29 PM, Alexandre Bergel wrote: >> This means that some other process (probably the finalization process, since #factorial creates a lot of garbage) was running and/or gc happened during the "missing" 34.2%. The gc times are listed below. > > I also thought about that. But I doubt this is the only reason. I tried: > > MessageTally spyOn: [ 100 timesRepeat: [XMLDOMParser parse: (FileStream fileNamed: 'path to an xml file') contents ]]. > > and I obtain > -=-=-=-=-=-=-=-=-=-=-=-= > - 168 tallies, 168 msec. > > **Tree** > -------------------------------- > Process: (40s) 754188288: nil > -------------------------------- > 18.5% {31ms} XMLDOMParser>>parseDocument > 18.5% {31ms} XMLDOMParser(SAXHandler)>>parseDocument > 18.5% {31ms} XMLParser>>parseDocument > 18.5% {31ms} XMLParser>>parseToken > 18.5% {31ms} XMLTokenizer>>nextToken > 16.1% {27ms} XMLTokenizer>>nextMarkupToken > -=-=-=-=-=-=-=-=-=-=-=-= > > The memory stat are > -=-=-=-=-=-=-=-=-=-=-=-= > > **Memory** > old +120,524 bytes > young -442,960 bytes > used -322,436 bytes > free +322,436 bytes > > **GCs** > full 0 totalling 0ms (0.0% uptime) > incr 12 totalling 5ms (3.0% uptime), avg 0.0ms > tenures 2 (avg 6 GCs/tenure) > root table 0 overflows > -=-=-=-=-=-=-=-=-=-=-=-= > > > The factorial example consumes more memory, and it is reported to consume 72% > > Something is weird. I will look into it. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 24, 2011

Re: [Pharo-project] Good practicces! Looking for examples

by StÃ©phane Ducasse

On Dec 24, 2011, at 3:07 PM, Alexandre Bergel wrote: > Not sure what you mean with good coding practice, but here my contrib: > > - the command pattern (e.g., OB, Mondrian Easel, MonticelloBrowser) > - symbol polymorphic to block and other object-as-function Not sure that this is a good practices. I think that you like them because you use Smalltalk as a DSL. > - writing test before fixing code > - having short methods indeed Here is what I started to write.

Dec. 24, 2011

Re: [Pharo-project] Wrong number with message tally?

by Alexandre Bergel

> This means that some other process (probably the finalization process, since #factorial creates a lot of garbage) was running and/or gc happened during the "missing" 34.2%. The gc times are listed below. I also thought about that. But I doubt this is the only reason. I tried: MessageTally spyOn: [ 100 timesRepeat: [XMLDOMParser parse: (FileStream fileNamed: 'path to an xml file') contents ]]. and I obtain -=-=-=-=-=-=-=-=-=-=-=-= - 168 tallies, 168 msec. **Tree** -------------------------------- Process: (40s) 754188288: nil -------------------------------- 18.5% {31ms} XMLDOMParser>>parseDocument 18.5% {31ms} XMLDOMParser(SAXHandler)>>parseDocument 18.5% {31ms} XMLParser>>parseDocument 18.5% {31ms} XMLParser>>parseToken 18.5% {31ms} XMLTokenizer>>nextToken 16.1% {27ms} XMLTokenizer>>nextMarkupToken -=-=-=-=-=-=-=-=-=-=-=-= The memory stat are -=-=-=-=-=-=-=-=-=-=-=-= **Memory** old +120,524 bytes young -442,960 bytes used -322,436 bytes free +322,436 bytes **GCs** full 0 totalling 0ms (0.0% uptime) incr 12 totalling 5ms (3.0% uptime), avg 0.0ms tenures 2 (avg 6 GCs/tenure) root table 0 overflows -=-=-=-=-=-=-=-=-=-=-=-= The factorial example consumes more memory, and it is reported to consume 72% Something is weird. I will look into it. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2011