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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project