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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |