Important addition on 19.04.09: James Robertson of Cincom pointed out in his blog that the speed of namespaces has improved in VW 7. I cannot comment this (but I trust him), because we are not on VW 7. Therefore, please keep in mind that my following comments apply only to older VW releases.
-------------------------------------------------------------
A technical foreword: The sequence of my postings does not reflect the importance of the subjects.
In VisualWorks accessing classes by their namespaces bindings is very slow!
Unfortunately, both Seaside as well as the Swazoo classes use namespace bindings. This is in some cases needed, because the authors of these classes refuse to use a stringent naming convention for their classes like in the WABlahBlah cases, which is good but not yet applied to all classes.
When testing our application I was wondering why making a timestamp took such a long time! I found out that the reason was solely in the use of namespace bindings throughout many classes (primarily Swazoo and ported Squeak classes).
I have removed these namespace bindings and this decreased the time by more than 70% !!!
Therefore, I recommend you to make these changes:
1) Rename all classes to follow a stringent naming convention. The first two or three characters must under all circumstances start with a homogeneous number of characters, which identify the application. WABlahBlah is good. But it must apply to all classes.
2) Remove all usages of "Namespace.ClassName". This is slow. The class name alone will be sufficient.
3) We find it cleaner to never store the expressive class name but to use symbols like in: #XYZMyClass asClass. This avoids undeclareds when a system is configured in different versions, which might not comprise of all classes (frequently the case for us). In such cases and for speed purposes a static in class String does perfectly well, which translates "asClass" to the wanted class. But, of course, this is more a matter of taste.
Two remarks:
1) This does not contradict my previous statement that execution speed (generally) does not matter. There was more involved than mentioned above and on a heavily used server this accumulates to simply a lot of wasted time.
2) A long time ago we have made an enhancement to compensate this VisualWorks performance problem so that we can send a message "asClass" to every symbol and string. It's a hack but very useful and very much quicker than going through the normal "binding value" thing. We have simply added a static to class String, which holds a dictionary where the keys are the class symbols and the values are the classes. This has improved the entire speed of our application considerably!
...more to follow soon!
Subscribe to:
Post Comments (Atom)
Care to explain the benchmark you're using? Namespace bindings become cached the first time they are used and cost the same as a non-namespaced class reference from then on.
ReplyDeleteNormally we use the VW Timeprofiler, which is very good, but in this case, due to the relatively short time needed, I just had milliseconds shown at the start and the end of the tested routine.
ReplyDeleteI doubt your statement about caching, because we have had this same problem before and this simple caching hack in a dict improved the speed of our apps considerably.
Best regards
The Smalltalk blogger
Can you post the code that you profiled?
ReplyDelete@Steve
ReplyDeleteWhat do you mean exactly?
Sorry let me try again. Can you post some sample VisualWorks code that demonstrates the performance problem you describe in this post?
ReplyDelete@Steve
ReplyDeleteThere is not code to post. It was just a Timestamp that was calculated (one statement). Initiated by Seaside this was done primarily by classes ported from Squeak. It went over three or four classes that were involved.
We then removed frem "Namespace.Class" the first part and it was more than 3 times faster (I think it was 640 down to 160ms) solely because of this. No other changes.
But as I wrote: I had found out the same long time ago.
And if you check here:
ReplyDeletehttp://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Misconceptions_on_Namespaces&entry=3417511969
You'll find that Michael is correct. Dot notation namespace refs are not, in fact, slower.
160ms still seems slow for calculating a timestamp (especially since most people probably use timestamps for benchmarking). I guess context is everything. I've never seen this behavior in VW - it would be good if you could clarify what you were trying to do and maybe someone could explain the root cause of the problem.
ReplyDelete@James Robertson
ReplyDeleteIn your blog you fully confirmed my statements, simply because we are not on VW 7. Porting our many changes and fixes would mean far too much work and we see very few advantages.
I do not know about VW 7.
@Steve
ReplyDeleteThank you for your comments. I don't find this context at the moment and really I don't consider this to be so very vital. It was one (rather less important) subject on my long list of Seaside deficiencies and I wanted to give Smalltalkers a little hint beyond Seaside.
In my view it'd be fully sufficient if library developers would all stick to the class naming convention "ABCBlahBlah" (ABC = some logical area or app), because then namespaces are for code menagement where I see their main advantage. This is in Seaside already quite good (WABlah) but not yet fully consistent.
Which Seaside version do you use?
ReplyDelete2.8
ReplyDelete