[vwnc] name and fullName

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] name and fullName

Stefan Schmiedl
A copy'n'paste from a workspace after two print-its

        Class name class name  #ByteSymbol
        Class fullName class name #ByteString

Well, actually, after two print-its following a half-hour of
head-scratching why an IdentityDictionary suddenly started
misbehaving.

What's the rationale behind this?

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Travis Griggs-3

On May 21, 2008, at 12:48 PM, Stefan Schmiedl wrote:

> A copy'n'paste from a workspace after two print-its
>
> Class name class name  #ByteSymbol
> Class fullName class name #ByteString
>
> Well, actually, after two print-its following a half-hour of
> head-scratching why an IdentityDictionary suddenly started
> misbehaving.
>
> What's the rationale behind this?

I will take a shot at what I think it might be. Class names are used  
to look things up in Dictionaries. Symbols will compare faster than  
Strings. And finding classes by their name is something the system  
does quite a bit. The fullName though is an aggregate of the classes  
name and the chain of its containing scopes. One could argue that  
there is no reason to ever look things up by this "stringified"  
representation of the path to a class (even though Store actually does  
I think). Add that to the fact that putting the string together is  
relatively fast, interning it as a symbol can be expensive, there's no  
reason to pay the price for something that isn't anticipated to happen  
much. It's not pedantically idea. But it is pragmatic.

--
Travis Griggs
Objologist
"It's [a spec] _the_ single worst way to write software, because it by  
definition means that the software was written to match theory, not  
reality" - Linus Torvalds


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Stefan Schmiedl
Hi Travis,

thanks for shedding some light on this.

On Wed, 21 May 2008 22:00:45 -0700
Travis Griggs <[hidden email]> wrote:

> But it is pragmatic.

As per your classification in the Collection thread:

> Is the desire for consistency here motivated by:
> A) I was looking at the code, noticed it was different, thought that  
> might not be a good thing, because it was inconsistent.
> B) I was using the code, and expected a different result, so was a bit  
> surprised, but I was not depending on the consistency.
> C) I wrote code that depended on the consistency, and got burned by it  
> not being so.

My case above was definitely a C :-)

To elaborate:

> One could argue that  
> there is no reason to ever look things up by this "stringified"  
> representation of the path to a class

which is exactly what I was doing, as all of my "persistent"
objects were referenced from a IdentityDictionary keyed by
class name. As the system evolved, an additional namespace
appeared, so I dimly recalled the method "fullName" and did
not check what it acutally answers.

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Travis Griggs-3
On May 22, 2008, at 11:05 AM, Stefan Schmiedl wrote:

> Hi Travis,
>
> thanks for shedding some light on this.
>
> On Wed, 21 May 2008 22:00:45 -0700
> Travis Griggs <[hidden email]> wrote:
>
>> But it is pragmatic.
>
> As per your classification in the Collection thread:
>
>> Is the desire for consistency here motivated by:
>> A) I was looking at the code, noticed it was different, thought that
>> might not be a good thing, because it was inconsistent.
>> B) I was using the code, and expected a different result, so was a  
>> bit
>> surprised, but I was not depending on the consistency.
>> C) I wrote code that depended on the consistency, and got burned by  
>> it
>> not being so.
>
> My case above was definitely a C :-)
>
> To elaborate:
>
>> One could argue that
>> there is no reason to ever look things up by this "stringified"
>> representation of the path to a class
>
> which is exactly what I was doing, as all of my "persistent"
> objects were referenced from a IdentityDictionary keyed by
> class name. As the system evolved, an additional namespace
> appeared, so I dimly recalled the method "fullName" and did
> not check what it acutally answers.


One lesson I've taken from experiences similar to yours is that I  
really rarely have a good reason to use IdentityDictionaries. I think  
I do. But I'm usually just needlesly constraining the problem. And  
think I'm getting some speed benefit that I'm not really. YMMV of  
course.

Please don't take this as an attempt to dodge what surprised you and  
broke for you. Been there, done that. And will again for sure. Mine  
was simply an attempt to guess at/explain why it was the way it was.

--
Travis Griggs
Objologist
"Only one thing is impossible for God: to find any sense in any  
copyright law on the planet." - Mark Twain


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Stefan Schmiedl
On Thu, 22 May 2008 21:17:28 -0700
Travis Griggs <[hidden email]> wrote:

> One lesson I've taken from experiences similar to yours is that I  
> really rarely have a good reason to use IdentityDictionaries. I think  
> I do. But I'm usually just needlesly constraining the problem. And  
> think I'm getting some speed benefit that I'm not really. YMMV of  
> course.

Interesting. I'll think about my organization again and run some
test, if I get the chance. Case in point: Why am I using the class name
at all? Will bad things happen if I just use the class object itself as
key in a dictionary? Fun times ahead :-)

> Please don't take this as an attempt to dodge what surprised you and  
> broke for you. Been there, done that. And will again for sure. Mine  
> was simply an attempt to guess at/explain why it was the way it was.

Much appreciated. I expect to find a few surprises here and there as
my usage of VW increases. An explanation (or even rationalization) of
the why behind the how helps remembering all of this.

Thanks,
s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Travis Griggs-3

On May 23, 2008, at 6:28 AM, Stefan Schmiedl wrote:

> On Thu, 22 May 2008 21:17:28 -0700
> Travis Griggs <[hidden email]> wrote:
>
>> One lesson I've taken from experiences similar to yours is that I
>> really rarely have a good reason to use IdentityDictionaries. I think
>> I do. But I'm usually just needlesly constraining the problem. And
>> think I'm getting some speed benefit that I'm not really. YMMV of
>> course.
>
> Interesting. I'll think about my organization again and run some
> test, if I get the chance. Case in point: Why am I using the class  
> name
> at all? Will bad things happen if I just use the class object itself  
> as
> key in a dictionary? Fun times ahead :-)

You caused me to be curious. Creating a bunch of Symbols and then  
repeatedly accessing them from a Dictionary vs an IdentityDictionary.  
I showed that the IdentityDictionary is worth about 3% speedup. Not a  
compelling reason (for me at least) to use it. Unless I truly want to  
avoid equality. Test code I used below the sig.

<snip>

--
Travis Griggs
Objologist
10 2 letter words: "If it is to be, it is up to me"

symbols := ((Object comment asString runsFailing: #isSeparator) collect:
                #asSymbol) asArray.
d := Dictionary new.
symbols
        do:
                [:each |
                d
                        at: each
                        put: Object new].
(Time
        millisecondsToRun:
                [100000
                        timesRepeat:
                                [1
                                        to: symbols size
                                        do: [:n | d at: (symbols at: n)]]]) out.
d := IdentityDictionary new.
symbols
        do:
                [:each |
                d
                        at: each
                        put: Object new].
(Time
        millisecondsToRun:
                [100000
                        timesRepeat:
                                [1
                                        to: symbols size
                                        do: [:n | d at: (symbols at: n)]]]) out
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] name and fullName

Stefan Schmiedl
On Fri, 23 May 2008 08:34:17 -0700
Travis Griggs <[hidden email]> wrote:

> You caused me to be curious. Creating a bunch of Symbols and then  
> repeatedly accessing them from a Dictionary vs an IdentityDictionary.  
> I showed that the IdentityDictionary is worth about 3% speedup. Not a  
> compelling reason (for me at least) to use it. Unless I truly want to  
> avoid equality. Test code I used below the sig.

hmm... if you already have symbols, IdentityDictionaries are not a big
win, it seems.

But I'm wondering about the speedup of using Strings in Dictionaries
vs. Symbols in IdentityDictionaries, the idea of the latter combination
being that equal symbols are the same anyways.

Oh my ... I ran your code a few times from a workspace and the results
are ... surprising:

8163 9781
7051 9588
6929 9582

Dictionaries are the first column, IdentityDictionaries the second.

Comparing Symbols@Dictionary to Strings@Dictionary gives a clear
result for using Symbols: they are twice as fast. However, if you have
to call asSymbol to get them from a string you have, it takes twice as
long.

So my image tells me to use Symbol@Dictionary, if I can,
String@Dictionary otherwise.

Very educational, actually trying things out :-)

s.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc