Squeak 3.7 ish - I've got this meta model that stores attribute names as symbols.
I frequently derive labels from the attribute names and this often ends up calling #capitalized on the symbol.
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbol
I found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor:
I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string.
So, in the name of performance, I vote to nuke this method or change it to just return a string.
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbolI found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor:
I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string.
So, in the name of performance, I vote to nuke this method or change it to just return a string.
I would be much more convinced if you had said "I've been making this change to all my programs for the past year and have never ran into any difficulty because of it."
There isn't much risk if you make that change to your image because you will remember that you made the change and if you run into a problem because of it, you'll probably catch it right away. However, if we make the change to the standard image then it might change the behavior of someone's application who doesn't know the change was made and so will have a hard time figuring out what happened.
I suggest you make that change in all your programs and report back next year. In fact, I encourage lots of people to make that change. Then, when we have a debate in a year we can have testimonials like "I tried it and everything was fine" or "I tried it and it broke XXX". That would be the right time to make the change. Or not.
Performance improvements are good, and we want to be continually making them. Hoever, they are rarely critical, and it is better to check them out carefully before making them.
-Ralph Johnson
That sounds like a fine idea - I'll definitely continue to check it out.
I did spot a case or two where the point was to ultimately generate a symbol, but capitalized was an intermediate result so you ended up interning a bunch of intermediate results that were never used.
On Jan 2, 2007, at 2:13 AM, Ralph Johnson wrote:
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbolI found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor:
I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string.
So, in the name of performance, I vote to nuke this method or change it to just return a string.
I would be much more convinced if you had said "I've been making this change to all my programs for the past year and have never ran into any difficulty because of it."
There isn't much risk if you make that change to your image because you will remember that you made the change and if you run into a problem because of it, you'll probably catch it right away. However, if we make the change to the standard image then it might change the behavior of someone's application who doesn't know the change was made and so will have a hard time figuring out what happened.
I suggest you make that change in all your programs and report back next year. In fact, I encourage lots of people to make that change. Then, when we have a debate in a year we can have testimonials like "I tried it and everything was fine" or "I tried it and it broke XXX". That would be the right time to make the change. Or not.
Performance improvements are good, and we want to be continually making them. Hoever, they are rarely critical, and it is better to check them out carefully before making them.
-Ralph Johnson
Todd Blanchard wrote:
I did spot a case or two where the point was to ultimately generate a symbol, but capitalized was an intermediate result so you ended up interning a bunch of intermediate results that were never used.
Just glancing over a few places it's pretty obvious that at least CategoryViewer>>getterTilesFor:type: and SlotInformation class>>type and StandardScriptingSystem>>colorForType: all require #capitalized to return symbols, not strings.
Cheers, - Andreas
On Jan 2, 2007, at 2:13 AM, Ralph Johnson wrote:
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbolI found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor:
I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string.
So, in the name of performance, I vote to nuke this method or change it to just return a string.
I would be much more convinced if you had said "I've been making this change to all my programs for the past year and have never ran into any difficulty because of it."
There isn't much risk if you make that change to your image because you will remember that you made the change and if you run into a problem because of it, you'll probably catch it right away. However, if we make the change to the standard image then it might change the behavior of someone's application who doesn't know the change was made and so will have a hard time figuring out what happened.
I suggest you make that change in all your programs and report back next year. In fact, I encourage lots of people to make that change. Then, when we have a debate in a year we can have testimonials like "I tried it and everything was fine" or "I tried it and it broke XXX". That would be the right time to make the change. Or not.
Performance improvements are good, and we want to be continually making them. Hoever, they are rarely critical, and it is better to check them out carefully before making them.
-Ralph Johnson
"Ralph Johnson" johnson@cs.uiuc.edu writes:
I suggest you make that change in all your programs and report back next year. In fact, I encourage lots of people to make that change. Then, when we have a debate in a year we can have testimonials like "I tried it and everything was fine" or "I tried it and it broke XXX". That would be the right time to make the change. Or not.
As an aside, having a public package universe can provide more input to these decisions. The idea is, packages include self tests, and you have a package universe listing the packages that you want to continue to support. Then, whenever you are considering a change, you can make it locally and then run all of the packages' self tests to see if anything broke.
There are a few aspects to this approach to keep in mind. One is that you need a way to associate tests and packages. Whereas Scala uses the filesystem for this [1], Squeak could use a registry object.
Second, you have to have a list of packages that you care about. A package universe works can itself be such a list. SqueakMap also have version tags that you can use, although for some reason these tags are not always up to date. Whatever you do, though, you have to have SOME kind of list of relevant packages. How to develope that list is a fascinating question.
-Lex
[1] From http://permalink.gmane.org/gmane.comp.lang.scala/2894 :
To register a self test, the package should include a file whose name is misc/sbaz-testall/tests/package-name, where package-name is the name of the package with a self test. The contents of the file should be a single line with the name of the object or class holding the self test.
I would not recommend this. Normally, one would expect that a transformation like #capitalized would return an object of the same class. It would make more sense to define #asCapitalizedString and change the code to use it.
Terry
=========================================================== Terry Raymond Smalltalk Professional Debug Package Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 traymond@craftedsmalltalk.com http://www.craftedsmalltalk.com ===========================================================
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Todd Blanchard Sent: Monday, January 01, 2007 7:05 PM To: The general-purpose Squeak developers list Subject: Symbol>>capitalized?
Squeak 3.7 ish - I've got this meta model that stores attribute names as symbols.
I frequently derive labels from the attribute names and this often ends up calling #capitalized on the symbol.
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbol
I found this while watching the process browser running a lengthy script in the background and found about 80% of time was spent in WeakSet scanFor:
I did a search of the image and couldn't find a single instance of sending capitalized to a symbol where the caller was going to use it as a symbol rather than a string.
So, in the name of performance, I vote to nuke this method or change it to just return a string.
On Jan 1, 2007, at 16:04 , Todd Blanchard wrote:
I generally figure any string manipulation on a symbol results in a string but Symbol>>capitalized is implemented as
capitalized
^self asString capitalized asSymbol
How about the following:
capitalizedString ^self asString capitalized
capitalized ^ self capitalizedString asSymbol
?
Marcel
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Lex Spoon -
Marcel Weiher -
Ralph Johnson -
Terry Raymond -
Todd Blanchard