about keys returning a set

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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

See also

http://code.google.com/p/pharo/issues/detail?id=1353
http://code.google.com/p/pharo/issues/detail?id=1542

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 ?

Nicolas

2009/12/4  <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I see. . . this is an interesting observation (about the performance
penalty) on the issues of going really OO.
 
In retrospect I think (once the concerns about the possibility of changing
the semantics of the returned object) this is the way to go.

We really need to have a competitive (in terms of raw computing performance)
system!

Em 04/12/2009 16:46, Lukas Renggli < [hidden email] > escreveu:


Yeah, this was my first attempt, but this implementation is ways
slower. The block activations with #collect: matters. My
implemebtation only calls primitives or inlined constructs. Not nice
to look at, but as fast as it can get.

Lukas


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 :)


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas

in 1354 you change

whichClassDefinesClassVar: aString
        ^self whichSuperclassSatisfies:
                        [:aClass |
                        (aClass classVarNames collect: [:each | each asString])
                                includes: aString asString]

why not returning #() instead of nil?


whichClassDefinesClassVar: aString
        Symbol hasInterned: aString ifTrue: [ :aSymbol |
                ^self whichSuperclassSatisfies:
                        [:aClass |
                        aClass classVarNames anySatisfy: [:each | each = aSymbol]]].
        ^nil

I saw that you have second version but it did not change it.

Then I saw that you often do
        ... array sort

I imagine that this is because like that you keep the same semantics in client code.
Now may be one of these days we could fix the class builder to inforce the order.
Naively I was dreaming that classVar would be sorted once for all.

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I did it in 11071
        -> #()


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project