On Sat, 16 Jun 2001, Casey Lucas wrote:
> ok. just let me know when you think it's appropriate to
> start adding some tag optimizations.
I assume the changes will be local to 2-3 generators and runtime. We
should be able to have them in parallel, it would generate some conflicts
in cvs but we can easily merge them. On the other side, it would help me a
lot to have more pairs of eyes to validate the refactored architecture
as it moves forward.
> > Separating tree is very important to allow modules to do various
> > optimizations ( like replacing common tags with equivalent in-line java
> > code ) and to do the direct bytecode generation.
>
> regarding "replacing common tags with equivalent in-line java code": what
> exactly did you have in mind?
Some tags are likely to be used very frequently ( for, if, etc). A simple
thing we can do is to take the JspTree ( after separating the page
representation from the generators with visitor-like pattern ) and do a
number of optimizations before generating the code.
This is one of the simplest - walk the tree and look for some tags, and
replace them with equivalent in-line java code. That would save quite a
bit of overhead - creating and pooling the tag, manipulating the variables
via hashtables, multiple method invocations.
There are many other optimizations that we can do on the tree ( including
elimination of duplicated initializers, etc) - that's how most compilers
work.
If you remember the discussion about XSLT, that's one of the places I
thing it might make a big difference. The code to do more advanced
processings on the tree can get extremely complex - and will end up
duplicating a lot from xslt ( we'll just do tree manipulations - searching
for patterns in a tree and generating tree fragments ). XSLT has all the
power it needs to do that and provide a standard behavior, as oposed to an
internal API we can define ( assuming we duplicate most of the code from
xslt ).
For simple things like replacing tags with equivalent java scriptlets we
don't need to wait for XSLT, but long term the code can become very hard
to understand as it starts doing advanced things ( by duplicating the
xpath and templates ).
BTW, that does _not_ matter for a developer - optimizations could be
easily turned off so it'll not affect the compile time for development
mode. It will matter when you deploy on a production server where few
modifications happen ( or off-line precompilation is used ) - and the
extra time it takes to optimizat the code is not important.
Costin
