Re: Optimising #include creation of FastWriter

On Fri 17 March 2006 11:23, Endre St=F8lsvik wrote:
> 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 sta=
te
> | 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 understand exactly what you have at the moment, and I understand what is=
=20
being suggested, but let me just recap for a moment:-

=2D you have a series of portlets.  Currently you are rendering these by=20
creating a new Context and a new FastWriter, doing all the work and then=20
dropping the contents of the FastWriter (which will either contain your=20
portlet or your error report) into the master FastWriter.

=2D you are proposing to save the creation time of a new FastWriter by usin=
g the=20
master FastWriter for the global template page and resetting it as necessar=
y=20
to handle the consequences (I think the use of flush in your mark/reset/flu=
sh=20
is maybe what is confusing because flushing by definition drops the content=
s=20
of the FastWriter out to the output stream which is probably not what you=20
mean).

Now, just for a moment in order to play devils advocate:  supposing that we=
 do=20
have this #flush command that Keats mentioned, and suppose one of your=20
portlet implementors executes #flush inside one of your portlet and the byt=
es=20
(both before and after your mark) are flushed out to the output stream.  Yo=
u=20
then try and do a reset, but the reset point along with all the data before=
=20
and after it has already been sent down-stream.

Personally, I think that you already have a nicely encapsulated safe struct=
ure=20
for your portlets with a dedicated Context and a dedicated FastWriter for=20
each portlet.  Error failure is encapsulated and you don't drop the result =
of=20
your parsing / error catching out to your master FastWriter until it is=20
completed.  If you are concerned about the overhead of generating lots (1 p=
er=20
portlet) of new FastWriter instances, then I would use just one FastWriter=
=20
that is shared between all of your Portlets, and your sequence would be:-

=2D create Portlet FastWriter
=2D foreach portlet in portlets
  - create new Portlet Context
  - reset Portlet FastWriter
  try {
    - render portlet with Portlet Context to Portlet FastWriter
  } catch (exception) {
    - reset FastWriter
    - render error with Portlet Context to Portlet FastWriter
  }
  - write Portlet FastWriter to Servlet FastWriter
}
=2D write Servlet FastWriter to OutputStream

Now, you still have all of your encapsulation, your rollbacks work, you are=
=20
creating at most one FastWriter beyond where you are, and it really doesn't=
=20
matter what happens inside the rendering loop and you don't need to make an=
y=20
functional changes to how the FastWriter works.  Or am I missing something?

(you should also look at the overhead of Context initialisation - HashMap a=
nd=20
ConcurrentHashMap usage are by far the greatest CPU hogs in my tree at=20
present)

<snip>

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