Re: Optimising #include creation of FastWriter

On Mon, 13 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote:

| >
| > 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?

Yes.

But assuming that the Portlets aren't _pure_ evil, this would have been a 
big thing: I could just have recreated the initial state before each 
rendering, by using a "weird-long-named" context-var for "my state", 
hoping that the corelet wouldn't intentially mess things up.

But I do make a new Context, due to this concern.

| 
| > 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. 

Why is that? This seems completely illogical to me, I can't see at all 
where you're coming from.

If I still make new Contexts, and you understand that each portlet is "on 
its own" (with a logical separate context too), and if I don't commit 
bytes to the browser-stream before flush, then "rolling back" is _exactly_ 
the same as ditching the buffer, _as I do now_.

| 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.

Make a new one?!

.. or as suggested above.

| 
| 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"
| }

Of course - which can't contain errors.

| 
| 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.

People don't program fantastic code. Suddenly, some method returns null. 
Suddenly, some seldom-used if-case kicks in, and everything goes haywire.

I really can't understand why my needs are so non-understandable?!

I am not constructing some obscure use-case here: This "damage control" is 
what I do now, I'd just like to have a more optimized way of doing it 
using the features that actually are present in the fastwriter already.

| 
| 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.

I use JProfiler, but thanks for the tip.

Endre


-------------------------------------------------------
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&kid=110944&bid=241720&dat=121642