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

Re: [Pharo-project] question about results of MessageTally

by Laval Jannik

yes, with 0 it works. But, in some cases, we would like to have all branches. So, I will do the method spyOn:cutoff:, and keep the 1% threshold for spyOn:. Cheers, Jannik On Oct 25, 2009, at 20:54 , Adrian Lienhard wrote: > Have you tried with 0? I guess you get way too much in the tree > (especially when you trace a larger part of your application and not > only adding elements to a dictionary). It seems that 1% is a sensible > default as usually it does not make sense to look into these branches > more closely as you cannot optimize them much. > > Adrian > > On Oct 25, 2009, at 19:42 , Laval Jannik wrote: > >> Hi Adrian, >> >> Now I understand the "problem". >> So we can use "report:cutoff:" which allows us to give a specific >> value for the threshold. >> >> I will create a new method, spyOn:cutoff:. >> >> I think the method "spyOn:" must have the threshold equals to 0. >> No ? >> >> Cheers, >> Jannik >> >> >> On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: >> >>> Hi Jannik, >>> >>> Interesting question! >>> >>> You left out an important part oft the tally: the part about GC >>> activity. >>> >>> For the large dictionary I get: >>> >>> **GCs** >>> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >>> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >>> >>> That is, 95% of time is spent in GC! A lot of incremental GC cycles >>> are triggered because for each at:put: a new association instance is >>> created. The larger the dictionary, the larger is the new memory >>> space >>> and hence the incremental GC takes longer to complete. In the above >>> tally the average was 49ms compared to >>> >>> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >>> >>> for the smaller dictionary. Therefore, the ratio between actual >>> method >>> execution time and GC time differs significantly between the two >>> runs. >>> As a result, a lot of branches of the tally are below a total of 1% >>> runtime in the second case. Message tally has a threshold that cuts >>> off branches with less than 1% runtime. Therefore you see less >>> details. >>> >>> Cheers, >>> Adrian >>> >>> >>> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >>> >>>> Hi, >>>> >>>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>>> results have not the same details according to the size of >>>> Dictionary. >>>> >>>> For example: >>>> === >>>> |n| >>>> MessageTally spyOn:[ >>>> n := Dictionary new. >>>> 1 to: 400000 do:[:each | n at: each put:each]. >>>> ] >>>> === >>>> >>>> returns this results: >>>> >>>> ==== >>>> - 1745 tallies, 1751 msec. >>>> >>>> **Tree** >>>> -------------------------------- >>>> Process: (40s) 1964: nil >>>> -------------------------------- >>>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>>> | |39.4% {690ms} Dictionary(Set)>>grow >>>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>>> | | | | |1.6% {28ms} primitives >>>> | | | |2.0% {35ms} primitives >>>> | | |9.2% {161ms} primitives >>>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>>> | |2.4% {42ms} primitives >>>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>>> |2.2% {39ms} primitives >>>> 22.4% {392ms} Association class>>key:value: >>>> |18.9% {331ms} Association class(LookupKey class)>>key: >>>> | |16.3% {285ms} Association(LookupKey)>>key: >>>> | |2.6% {46ms} primitives >>>> |1.9% {33ms} Association>>value: >>>> |1.6% {28ms} primitives >>>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>>> |2.3% {40ms} primitives >>>> |2.1% {37ms} Dictionary>>scanFor: >>>> 1.9% {33ms} primitives >>>> ==== >>>> >>>> But, if I do: >>>> === >>>> |n| >>>> MessageTally spyOn:[ >>>> n := Dictionary new. >>>> 1 to: 4000000 do:[:each | n at: each put:each]. >>>> ] >>>> === >>>> >>>> results are: >>>> ==== >>>> - 179772 tallies, 180312 msec. >>>> >>>> **Tree** >>>> -------------------------------- >>>> Process: (40s) 1964: nil >>>> -------------------------------- >>>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>>> | 2.3% {4147ms} Dictionary(Set)>>grow >>>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>>> 1.0% {1803ms} Association class>>key:value: >>>> ==== >>>> >>>> Where are the rest of the process ? >>>> Does anybody understand this behavior ? can you explain ? >>>> >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> --- >> >> >> _______________________________________________ >> 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 --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

Oct. 25, 2009

Re: [Pharo-project] [ANN] Pharo rc1dev10491 - Win32 Installer

by StÃ©phane Ducasse

yeap! Thanks Stef On Oct 25, 2009, at 8:56 PM, Adrian Lienhard wrote: > Thanks, Torsten! > > Adrian > > On Oct 25, 2009, at 20:49 , Torsten Bergmann wrote: > >> Forgot to mention: >> >> Windows Installer 1.0-10491-rc1dev09.10.5 is up >> on the download page. >> >> Bye >> Torsten >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> 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. 25, 2009

Re: [Pharo-project] Thread-safe collections

by StÃ©phane Ducasse

On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > Stef, > > With no disrespect to Sig's opinions, I'm glad to hear that. I very > quickly cobbled together a class called SharedLookupTable, and have > no problems making it (suitably debugged) available. > > Now it's time for me to kick your ass a little, to coin a phrase :) no problem > Monticello is pretty good at what it does, but I sense the things it > does not do interfering with good decision making. The class ended > up in my Dolphin compatibility package, in part because it belongs > there, though it really should be separate so I can easily release > it and people would be able to get it w/o having to accept other > ideas they might not want. But it went in the compatiblity package > so I would not have to mess around with another package. Saving > them is a pain; loading them into a new image is a pain. why? > Saving: the interface works well once understood, and the features > it offers should never go away. However, either by script or by > multiple selection, it would be nice to provide a comment to be > applied to everything to be saved "now" vs. having to be prompted > for it, then have the list scroll, then have to click away another > window. Do that 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? > Loading: I spent a chunk of yesterday trying to build an RC1 image. > Doing so revealed that my script-loader for script-loader does not > validate package names. I had one build attempt come to a halt over > case-sensitivity; I do not mind that. What I mind is that the > particular case mix in question was more or less forced on me by a > typo of mine. If MC were better about offering choices when they > apply, I might not have typed it that way. > > I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well > The ideas above are probably not new, but I list them just in case. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > I would really like to see some packages getting implementing around > the idea of a couple of robust and well tested thread safe > collections. > > Stef > > On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > >> Sig, >> >> One can always construct examples in which protecting the entire >> loop is the better option. That's not the scenario of interest. >> Just as shared queues are useful, shared sets and dictionaries have >> value for sporadic access scenarios. Doing it your way, everyone >> writes their own incompletely protected (read buggy/dangerous) ad- >> hoc >> implementations of these common collections. >> >> I favor having solid implementations that are complete and as correct >> as we can get them, leaving people to optimize as you suggest when it >> makes sense to do so. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Hello all, >>> >>> I just looked around for thread-safe collections, and found nothing >>> that looks like a shared dictionary. The squeak-dev archives >>> contain >>> the obligatory newbie posts (wanting all collections to be thread >>> safe) and the expected replies, some of which are overly dismissive >>> of the idea. Something that protects things like >>> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >>> existing implementation? >>> >> >> Imo, there's only one shared collection which is useful - shared >> queue. :) If you need more kinds of thread-safe collections, it >> probably indicating that the concurrent code (or model) which you >> designed is in pretty bad shape. >> >> Just compare two following snippets: >> >> 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. >> >> and: >> >> semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: >> something] ]. >> >> What you think, which one is better? >> >> >>> Bill >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

Re: [Pharo-project] [ANN] Pharo rc1dev10491 - Win32 Installer

by Adrian Lienhard

Thanks, Torsten! Adrian On Oct 25, 2009, at 20:49 , Torsten Bergmann wrote: > Forgot to mention: > > Windows Installer 1.0-10491-rc1dev09.10.5 is up > on the download page. > > Bye > Torsten > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

Re: [Pharo-project] question about results of MessageTally

by Adrian Lienhard

Have you tried with 0? I guess you get way too much in the tree (especially when you trace a larger part of your application and not only adding elements to a dictionary). It seems that 1% is a sensible default as usually it does not make sense to look into these branches more closely as you cannot optimize them much. Adrian On Oct 25, 2009, at 19:42 , Laval Jannik wrote: > Hi Adrian, > > Now I understand the "problem". > So we can use "report:cutoff:" which allows us to give a specific > value for the threshold. > > I will create a new method, spyOn:cutoff:. > > I think the method "spyOn:" must have the threshold equals to 0. > No ? > > Cheers, > Jannik > > > On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: > >> Hi Jannik, >> >> Interesting question! >> >> You left out an important part oft the tally: the part about GC >> activity. >> >> For the large dictionary I get: >> >> **GCs** >> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >> >> That is, 95% of time is spent in GC! A lot of incremental GC cycles >> are triggered because for each at:put: a new association instance is >> created. The larger the dictionary, the larger is the new memory >> space >> and hence the incremental GC takes longer to complete. In the above >> tally the average was 49ms compared to >> >> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >> >> for the smaller dictionary. Therefore, the ratio between actual >> method >> execution time and GC time differs significantly between the two >> runs. >> As a result, a lot of branches of the tally are below a total of 1% >> runtime in the second case. Message tally has a threshold that cuts >> off branches with less than 1% runtime. Therefore you see less >> details. >> >> Cheers, >> Adrian >> >> >> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >> >>> Hi, >>> >>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>> results have not the same details according to the size of >>> Dictionary. >>> >>> For example: >>> === >>> |n| >>> MessageTally spyOn:[ >>> n := Dictionary new. >>> 1 to: 400000 do:[:each | n at: each put:each]. >>> ] >>> === >>> >>> returns this results: >>> >>> ==== >>> - 1745 tallies, 1751 msec. >>> >>> **Tree** >>> -------------------------------- >>> Process: (40s) 1964: nil >>> -------------------------------- >>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>> | |39.4% {690ms} Dictionary(Set)>>grow >>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>> | | | | |1.6% {28ms} primitives >>> | | | |2.0% {35ms} primitives >>> | | |9.2% {161ms} primitives >>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>> | |2.4% {42ms} primitives >>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>> |2.2% {39ms} primitives >>> 22.4% {392ms} Association class>>key:value: >>> |18.9% {331ms} Association class(LookupKey class)>>key: >>> | |16.3% {285ms} Association(LookupKey)>>key: >>> | |2.6% {46ms} primitives >>> |1.9% {33ms} Association>>value: >>> |1.6% {28ms} primitives >>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>> |2.3% {40ms} primitives >>> |2.1% {37ms} Dictionary>>scanFor: >>> 1.9% {33ms} primitives >>> ==== >>> >>> But, if I do: >>> === >>> |n| >>> MessageTally spyOn:[ >>> n := Dictionary new. >>> 1 to: 4000000 do:[:each | n at: each put:each]. >>> ] >>> === >>> >>> results are: >>> ==== >>> - 179772 tallies, 180312 msec. >>> >>> **Tree** >>> -------------------------------- >>> Process: (40s) 1964: nil >>> -------------------------------- >>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>> | 2.3% {4147ms} Dictionary(Set)>>grow >>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>> 1.0% {1803ms} Association class>>key:value: >>> ==== >>> >>> Where are the rest of the process ? >>> Does anybody understand this behavior ? can you explain ? >>> >>> >>> Cheers, >>> Jannik >>> >>> >>> _______________________________________________ >>> 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 > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

[Pharo-project] [ANN] Pharo rc1dev10491 - Win32 Installer

by Torsten Bergmann

Forgot to mention: Windows Installer 1.0-10491-rc1dev09.10.5 is up on the download page. Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Oct. 25, 2009

Re: [Pharo-project] Some bugs I ran into while working on hashing

by StÃ©phane Ducasse

nicolas if you produce a slice I will integrate them. For now I'm focusing on emptying the pending stack of fixed items Stef On Oct 25, 2009, at 4:53 PM, Nicolas Cellier wrote: > 2009/10/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/10/25 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >>> >>> isPrime >>> >>> | guess guessSquared delta selfSqrtFloor | >>> self <= 1 ifTrue: [^self error: 'operation undefined']. >>> self even ifTrue: [^self = 2]. >>> guess := 1 bitShift: self highBit + 1 // 2. >>> [ >>> guessSquared := guess * guess. >>> delta := guessSquared - self // (guess bitShift: 1). >>> delta = 0 >>> ] whileFalse: [guess := guess - delta]. >>> guessSquared = self ifFalse: [guess := guess - 1]. >>> selfSqrtFloor := guess. >>> 3 to: selfSqrtFloor by: 2 do: [:each | self \\ each = 0 ifTrue: >>> [^false]]. >>> ^true >>> >>> >>> Also, the above code can be used to implement sqrtFloor and >>> sqrtRounded >>> in Integer. I am sure Nicolas Cellier remembers this :). >> >> If http://bugs.squeak.org were not down, I would even provide a link >> with these enhancements >> > > google says it should be http://www.google.fr/bugs.squeak.org/view.php?id=7099 > . > Or go to the source > http://blogten.blogspot.com/2008/06/drove-to-reno-today.html > http://blogten.blogspot.com/2008/06/update-on-sqrtrounded.html > > >>> >>> Andres. >>> >>> _______________________________________________ >>> 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. 25, 2009

Re: [Pharo-project] hashing collections

by Ralph Boland

> > Watch out for cancellation effects... if the collections are > sequenceable and the hash values of their contents are not well > distributed, you may end up with performance issues because the hash > values cancel each other because the hash function commutes. Â Consider > for example the hash value of the following collections: > > #(1 2 3) > #(1 2 3 4 4) > #(1 2 3 5 5) > #(1 4 2 3 4) > #(5 4 3 2 1 4 5) > > #(6) > #(1 2 3 4 5 6 5 4 3 2 1) > > I am not familiar with your application, though, so perhaps the data > does not cause these problems. > > Andres. > You are right. These are serious problems with my idea and I retract the proposal that the idea may be preferable to the problems we have with putting the standard collections into Sets and Dictionaries. It works well in my application because in each case the collections have no duplicates and order doesn't matter. That is, in my application, the hash collections are all effectively sets or dictionaries in compacted form. I use a bit of code specific to my application to ensure they then are compared efficiently. Ralph > Ralph Boland wrote: >> Food for thought: >> >> In my finite state machine generator I do a lot of >> hashing of sometimes large collections. >> For performance reasons I created hash value storing versions >> of the relevant collection classes. Â Getting the hash value >> of the hashed version of a collection was then very fast >> (accessing an instance value) and the hash values were good. >> >> For example, for Array I created HashArray Â The hash >> value of a HashArray was the XOR of the hash values of >> the elements of the HashArray. Â Note that this meant >> that each time you changed the entry in a HashArray >> you had to update the hash value. >> So for HashArray Â Â at: index put: object Â Â would look something >> like: >> >> Â Â Â hash := (hash xor: object hash) xor: (self at: index). >> Â Â Â super at: index put: object. >> >> If you like living on the edge you could instead leave out updating >> the hash value until you put the HashArray object where its hash >> value would be needed (like a Set or Dictionary (key)). >> This is of course error prone but then >> putting collections in Sets or Dictionaries (keys) >> is inherently error prone anyway because modifying the collection >> changes its hash value thus breaking every Set or Dictionary >> containing the collection. >> >> I would be temped to have all real collection classes (e.g. not Interval) >> not be storable in Sets or Dictionaries (key) at all and instead require >> hash versions of the collection be used but of course this would >> surely break a lot of things. >> >> Ralph Boland >> >> >>

Oct. 25, 2009

Re: [Pharo-project] Improve pharo modularity: a first step

by StÃ©phane Ducasse

yes we did the same in VW. Stef On Oct 25, 2009, at 6:45 PM, Bernhard Pieber wrote: > Hi StÃ©phane, > > Am 23.10.2009 um 12:50 schrieb StÃ©phane Ducasse: >> Jannik >> may be we should have >> >> PackageCore >> PackageTest >> PackageSetting >> PackageExamples > A convention we follow here is - for VA Smalltalk code, though: > - Package (includes all code needed at runtime) > - PackageDev (includes all code needed only at Development: tests, > scripts, tools) > > This allows for nicely separating runtime packages from those only > needed for development while keeping the numbers of packages smaller. > > Just my 2 cents. > > Cheers, > Bernhard > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 25, 2009

Re: [Pharo-project] question about results of MessageTally

by Laval Jannik

Hi Adrian, Now I understand the "problem". So we can use "report:cutoff:" which allows us to give a specific value for the threshold. I will create a new method, spyOn:cutoff:. I think the method "spyOn:" must have the threshold equals to 0. No ? Cheers, Jannik On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: > Hi Jannik, > > Interesting question! > > You left out an important part oft the tally: the part about GC > activity. > > For the large dictionary I get: > > **GCs** > full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms > incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms > > That is, 95% of time is spent in GC! A lot of incremental GC cycles > are triggered because for each at:put: a new association instance is > created. The larger the dictionary, the larger is the new memory space > and hence the incremental GC takes longer to complete. In the above > tally the average was 49ms compared to > > incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms > > for the smaller dictionary. Therefore, the ratio between actual method > execution time and GC time differs significantly between the two runs. > As a result, a lot of branches of the tally are below a total of 1% > runtime in the second case. Message tally has a threshold that cuts > off branches with less than 1% runtime. Therefore you see less > details. > > Cheers, > Adrian > > > On Oct 24, 2009, at 07:21 , Laval Jannik wrote: > >> Hi, >> >> when I use MassageTally>>spyOn: on the creation of a Dictionary, >> results have not the same details according to the size of >> Dictionary. >> >> For example: >> === >> |n| >> MessageTally spyOn:[ >> n := Dictionary new. >> 1 to: 400000 do:[:each | n at: each put:each]. >> ] >> === >> >> returns this results: >> >> ==== >> - 1745 tallies, 1751 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) 1964: nil >> -------------------------------- >> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >> |43.6% {763ms} Dictionary(Set)>>fullCheck >> | |39.4% {690ms} Dictionary(Set)>>grow >> | | |27.2% {476ms} Dictionary>>noCheckAdd: >> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >> | | | | |23.6% {413ms} Dictionary>>scanFor: >> | | | | |1.6% {28ms} primitives >> | | | |2.0% {35ms} primitives >> | | |9.2% {161ms} primitives >> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >> | |2.4% {42ms} primitives >> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >> |2.2% {39ms} primitives >> 22.4% {392ms} Association class>>key:value: >> |18.9% {331ms} Association class(LookupKey class)>>key: >> | |16.3% {285ms} Association(LookupKey)>>key: >> | |2.6% {46ms} primitives >> |1.9% {33ms} Association>>value: >> |1.6% {28ms} primitives >> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >> |2.3% {40ms} primitives >> |2.1% {37ms} Dictionary>>scanFor: >> 1.9% {33ms} primitives >> ==== >> >> But, if I do: >> === >> |n| >> MessageTally spyOn:[ >> n := Dictionary new. >> 1 to: 4000000 do:[:each | n at: each put:each]. >> ] >> === >> >> results are: >> ==== >> - 179772 tallies, 180312 msec. >> >> **Tree** >> -------------------------------- >> Process: (40s) 1964: nil >> -------------------------------- >> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >> |2.8% {5049ms} Dictionary(Set)>>fullCheck >> | 2.3% {4147ms} Dictionary(Set)>>grow >> | 1.3% {2344ms} Dictionary>>noCheckAdd: >> 1.0% {1803ms} Association class>>key:value: >> ==== >> >> Where are the rest of the process ? >> Does anybody understand this behavior ? can you explain ? >> >> >> Cheers, >> Jannik >> >> >> _______________________________________________ >> 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 --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

Oct. 25, 2009