Oh, man, I just love these threads :)
Jason Foster wrote:
>
> It may be a little pretentious to use the "RT" prefix, but this is a random
> thought, so here goes...
Hey, there is no such thing as "pretentious" here. even if I was the
first to use the term RT to indicate more abstract reasoning, I'm for
sure not the only one that does think that way.
> During some of my (admittedly small amounts of) work with Cocoon I have
> found myself having to deal with the generated source code for the sitemap
> and some XSP pages. Needless to say this was not a terribly pleasant
> experience.
Don't tell me.
> It occurred to me that the path a request takes through the sitemap, or the
> generation of content from an XSP page, can be seen as a slightly involved
> tree traversal.
I haven't really had the time to think about it, but I agree.
> In combination with the Strategy pattern from the GOF, I
> got the following crazy idea:
>
> Why not parse the sitemap and create an in-memory representation
> (DOM,JDOM,???) where each node references both a component (Reader,
> Transformer, etc.) and a traversal strategy. When a request comes in:
>
> 1. Create the appropriate object encapsulating the parameters, etc.
> 2. Request a thread from a request handling thread pool
> 3. Pass the thread the request object and the root of the sitemap tree
>
> Traversal of the tree basically consists of:
>
> 1. Request the strategy for the current node
> 2. Ask the strategy to do its thing
> 2a. Which in most cases is likely to be a pre-order traversal, I think
>
> For some reason the conceptual model of a bunch of request objects
> traversing the sitemap tree seems a lot clearer than the current approach.
Oh, most definately.
> Is this a good idea? I really don't know.
I'll tell you one thing: don't know if you had the patience to read thru
all the recent RT between Berin and I, but we both indicated that the
current technique to compile the sitemap is slow, hard to understand and
very impractical at least for Cocoon development.
The only place were sitemap compilation might have a place is for
binary-only cocoon webapps that need to be deployed in production, but
this is yet to be seen.
> It does everything the current
> approach does (I think), feels cleaner (to me) , and might make debugging
> easier (ask the request to report on the path through the tree that it
> took). Without trying I can't tell if it would be faster or slower, or what
> the RAM consumption would be.
For sure, the memory consumption would be worse for production
enviornments where sitemaps never change and better for development
environments where sitemaps continously change.
As far as speed goes, I've already submitted another RT that states that
using modern hotspot techniques, compilation might be just like good old
loop-unrolling optimization techniques that I used to do for game coding
on x86 assembly when I was younger: since the 386 was slow as hell on
loops, simply unroll the loop if you knew in advance the loop cycles and
avoid taking memory for he counter, increase the counter and test the
counter.
As processor technology evolved, unrolled loops forced level 1 cache to
fetch more frequently and RISC-ification techniques to fail to optimize
the hotspots since the hotspot was "diluted" in the unrolled loop.
Here I have the feeling we are doing the same mistake over again: the
sitemap was compiled when no hotspot tecnique was present and we had to
avoid excessive use of esternal recurrent logic when we could "unroll"
the tree traversal and let java execute it directly by transforming it
in code.
Today, as more modern JVMs are made available, we might find out that
unrolling the loop (compiling the sitemap) is slower than performing
repeatedly a simple and well packed algorithm (which will create an
hotspot and greatly optimized by JIT compilers, expecially on server
environments where the hotspot may lasts there for months untouched).
In theory, (if we are lucky) we might find out that such a code might
even be faster than if written directly in native code: in fact, such a
continous and dynamically adapting JIT polishing of the native code,
might turn out to perform real-time optimization that adapt on the type
of load, something that would be much harder to do if we were to rewrite
Cocoon in native code to make it faster.
In short, I welcome your proposal and suggest you to present the list a
more detailed plan that we can implement.
> I am really curious as to why Cocoon has adopted the XSLT code generation
> approach?
Yes, I bet. Well, here it is: I'm a lazy butt and you all know that.
Also, I hate coding: if somebody else does it, I'm happier. I love brain
work and I love to draw things on my whiteboard, but when I have to code
it, well, I do it just if necessary.
Last year, Giacomo and Ricardo were my guests for a weekend and we
discussed the sitemap in detail. Ricardo had already wrote the XSP
machinery that allowed code to be compiled, loaded, executed and
recompiled if changed. When looking for a solution to implement the
sitemap, we thought about applying the same design patterns applied to
the XSP (at that time, we were very excited about dynamic compilation
technology) and Giacomo ended up writing the stylesheets for the sitemap
code generator and a few other things.
In a matter of days, he had a sitemap implementation ready. We were
amazed, it worked, it was fast (actually lightspeed compared to Cocoon1)
and we were happy enough to avoid going deeper into the problem.
Until recently.
> It really seems to make debugging a pain, as well as placing a
> dependency on having a java compiler on the runtime system.
Absolutely, expecially given javac which is written only for command
line and has no stream in/out capabilities and is not redistributable.
> I haven't been
> trying too hard to figure out what the advantages to this approach are, but
> I haven't come up with any.
As I said (but I have no figures to prove this), I believe current
approach is a winner for JDK 1.1 and 1.2, while is very likely to fail
on all issues but memory consumption on JDK 1.3 and 1.4 (and very
likely, all future versions)
> I have no doubt that any interested readers will enlighten me :)
Hope I did.
> Anyways, I don my asbestos underwear in preparation for your replies...
Nah, flamewars on this list as are so rare you can even forget about
wearing it for years, like I did :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
