Le 08/06/2014 22:02, Cl��ment Bera a ��crit :
> Some collection protocols were optimized so your result makes sense.The profiles show it is faster on 1.4!
Although there are use of iskindOf: in the image (384), there are
> The current performance bottleneck for your application definitely comes
> from the use of isKindOf: based on your profiles. inheritsFrom: is
> called by isKindOf: I guess.
exactly 0 use case from DrGeo source code directly, but still impacted I
guess. The situation is not different from 1.4, only inheritsFrom: seems
a lot slower in 3.0.
What is strange, and may give some indication about what is happening
underneath, the script as execution goes on, is slower and slower under
Pharo 3.0. With Pharo 1.4, the execution speed is completely constant
(as perceived).
Ok. I added at the begining of the script a garbage collection. The
> Now be very careful the current GC has very strange side effect. Did you
> perform manually a full GC before each bench ?
result are more or less the same. Now I wonder could it be related to
collection during execution:
**Memory**
�� �� �� �� old �� �� �� �� �� �� +461,292 bytes
�� �� �� �� young �� �� �� �� �� -1,436,444 bytes
�� �� �� �� used �� �� �� �� �� ��-975,152 bytes
�� �� �� �� free �� �� �� �� �� ��+975,152 bytes
**GCs**
�� �� �� �� full �� �� �� �� �� ��0 totalling 0ms (0.0% uptime)
�� �� �� �� incr �� �� �� �� �� ��48 totalling 213ms (19.0% uptime), avg 4.0ms
�� �� �� �� tenures �� �� �� �� 8 (avg 6 GCs/tenure)
�� �� �� �� root table �� �� ��0 overflows
Hil