> See also > > http://code.google.com/p/pharo/issues/detail?id=1353 in 11071 ;)
> http://code.google.com/p/pharo/issues/detail?id=1542 "This is issue1353 isn't it ? Lukas proposed to keep a Set, but optimize its creation (with extra knowledge that same key hash code is used in both Set and Dictionary which breaks a bit encapsulation) However, even if the Set is created fast in #keys, the overall effect depends on usage made of these keys. For example a Set then iterates slower than an Array for such code: self keys select: [:e | e beginsWith: 'test'] Otherwise, the second advantage of an Array is that keys and values both are arrays in sync, which might be a nice property..." yes I agree I prefer to have both arrays in sync it is more regular. > I uploaded a SLICE that just add a few #asSet here and there. > Quasi-neutral as long as keys are Set, but enabling a switch to Array > for macro benchmarks purposes... > > May I also push > http://code.google.com/p/pharo/issues/detail?id=1354 > which is related but quite independent ? Yes this is on my todo to integrate but I wanted people to discuss it before. "The problem of current definition of classVarNames is precisly that they are unordered. The order is not defined by user, it just depend on the hash codes of classVarNames modulo the size of classPool, unless we sort them. Please look at usage." I totally agree with you nicolas I hate that the classVar changes randomly their order. in 11071 :) > > Nicolas > > 2009/12/4 <[email protected]>: >> I think this last assertion has to be tempered by another statistic: which is >> the relationship between iteration (a.k.a. uses of) and creation? >> >> -- >> Cesar Rabak >> >> >> Em 04/12/2009 09:48, Stéphane Ducasse <[email protected]> escreveu: >> >> >> this is interesting to see that this is still a guess game. >> Even with these numbers I cannot evaluate what could be a slowdown/pseed up >> impact on the complete system. I imgain that the ietration slow down should >> be minimal >> and compensated by the creation speed up. >> May be in the future when system will have a better knowledge of themselves >> we may end up having better tools... >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
