Re: Optimising #include creation of FastWriter

On Mon 13 March 2006 12:30, Endre Stølsvik wrote:
> | Just out of interest - how were you envisioning this rolling back
> | happening? Was it going to be a java space action or would it take place
> | during the template rendering phase?
>
> I already do this, dude - so all your arguments about why it ain't smart
> is simply not applicable.
>
> The clue is that this is a _portlet engine_, right? Every portlet operates
> on its own, and you may view the portal as an operating system with the
> portlets as applications. If you understand this view, then I guess you
> understand why containment of errors are both smart and correct, and the
> "internal state change" arguments are simply not interesting (Better to
> contain _one_ error than make it propagate all the way out to the users
> browser, so that he potentially can't see the portal page at all (due to
> messed up nesting of tables etc)).
>
> I do it using _a new_ FastWriter with a temporary backing, then if
> everything went right, I put the result to the FastWriter.

Do you use a seperate Context for each portlet as well?  If the portlet fails, 
then how do you roll the Context back to the state that it was in at the 
beginning of the evalaution of the portlet?

> This temporary backing paradigm obviously isn't the best, and a
> mark/reset/flush paradigm would be much better for my part.

I can see where you are coming from on this, but it is very hard to state what 
the side effects of flushing the FastWriter early and / or rolling it back to 
an earlier state.  I think that any such mechanism would need to be 
integrated with the same ability on the Context that was being used as well 
for it to be safe.

Either way, I'm trying not to create any functional changes to the code as a 
whole at present unless it is really broken as I am not up to speed enough on 
the internal architecture to state what the effect of the changes might be so 
I suspect that I'm not going to look at this just now.

However, my gut reaction from the profiling that I've done suggests that if 
what you are after is maximum performance from your system then the best way 
of evaluating your portlets would be:-

#foreach $portlet in $portlets {
  #include as template "$portlet.prepareView"
}

where the $portlet.prepareView prepares all the necessary state information 
associated with the current view.  If this all goes smoothly in javaspace 
then it returns the path to the standard view of the portlet, otherwise it 
returns the path to the error template.

of course you can still get an error while rendering your standard view, but 
if all of the classes and methods that you are exposing to the template are 
purely read only (ie the template is just a view rather than the controller) 
then the performance increase that you get from not scripting the work up in 
webmacro will be greater than the performance increase that you would get by 
not generating a new FastWriter for each portlet.  

WebMacro is great and quite surprisingly fast, but it isn't by definition as 
fast as doing the same thing in direct java code, so the less processing work 
that you perform inside the template, the better the ultimate performance 
would be.

I would highly recommend getting hold of a copy of OptimizeIt and actually 
benchmarking the performance of your portlet application before embarking on 
refactoring the FastWriter in such a manner.

Alex


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642