During my work today I detected how inefficiently Seaside handles file requests.
I was deeply shocked to see this highly complicated implementation, which over and over again makes the Smalltalk VM busy with inefficient operations, which could easily be handled in a much simpler fashion.
It does not need to be discussed that a web server must be extremely efficient and fast. This is not the case for Seaside!
As I was corrected by a comment, Seaside is not a web server in the precise technical sense. That is correct. Nevertheless, one generally speaks also of PHP as a web server although typically the actual server work is done by a front-end Apache. Therefore, I still stick to this term "web server" for Seaside even if it is not absolutely precise.
When a file requests comes in, the class WAFileHandler loops recursively through all the subclasses of all of those library classes, which were registered as "root classes" and executes aBlock on each of them.
This is not only highly inefficient and wasting a lot of CPU performance but it is also very difficult to debug (like Seaside in general) and to step through. Probably another intention to keep Seaside as a cryptic black box!
My concrete proposal, which is by no means perfect but involves minimum changes to the current situation: Introduce a static in class WAFileHandler, which answers a correlation (library name and method name) for every incoming file request.
A dictionary look up is extremely fast in Smalltalk (at least in VisualWorks) and certainly multiple times faster than the current implementation. At the same time one could also solve the problem that I am discussing in my next proposal.
That has another good side-effect: It would be much easier than today to switch between different libraries - even at run-time when a user wants to select his user-specific skin.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment