You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Burian, Todd" <tb...@interactapps.com> on 2002/02/21 17:50:27 UTC
VM Templates vs JSP, How does everyone find VM speed
Our compan is planning to migrate from jsp to Turbine/Velocity. I have noticed a few issues where it seems Velocity is slower tha JSP and it seems slower in general. What do all you gurus think?
W. Todd Burian
Senior Java Developer
317-658-5600
<http://www.interactapps.com/> interactapps.com
tburian@lldc.net
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Burian, Todd" <tb...@interactapps.com> writes:
> Our compan is planning to migrate from jsp to Turbine/Velocity. I
> have noticed a few issues where it seems Velocity is slower tha JSP
> and it seems slower in general. What do all you gurus think?
Hah! You've got to be kidding me. Turn on caching and Velocity edges
out JSP in speed (after the AST is parsed) and murders it as far as
usuability.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by John McNally <jm...@collab.net>.
it just seems like overkill. I don't see what is wrong with
$inner_content.render().
john mcnally
Daniel Rall wrote:
>
> John McNally <jm...@collab.net> writes:
>
> > Daniel Rall wrote:
> >
> >>
> >> A method which I've been tossing around to deal with this is to use a
> >> ReferenceInsertionEventHandler:
> >>
> >> http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20and%20Event%20Handlers
> >>
> >> $inner_content has a handle to some sort of processing mechanism which
> >> is triggered (tested for using instanceof) by the
> >> ReferenceInsertionEventHandler configured for your EventCartridge.
> >> The triggered code writes to the same output stream which the Writer
> >> you passed to mergeTemplate() uses.
> >
> > Why can't $inner_content just render the template to the same stream as
> > the outer_template is being written to. In this case
> > $inner_content.toString() would just return null or "" and the template
> > would be written to the stream when the toString() method was called.
> > This is not a proper use of the toString() method, it would probably be
> > better to have a better method name (e.g. render). In t3, there is a
> > Renderer (DirectRenderer) that writes directly to the stream and it is
> > used in layout templates to render navigations, screens, or portlets (or
> > whatever else you want to call the inner templates).
> >
> > What does a ReferenceInsertionEventHandler add to this? What am I
> > misunderstanding?
>
> ReferenceInsertionEventHandler allows you to have a render()-esque
> method (which is called by your handler). toString() returns "", and
> you escape the alluring trap of having toString() call render()
> directly (which would be an improper overloading of the toString()
> method, breaking the contract defined by java.lang.Object).
>
> Dan
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John McNally <jm...@collab.net> writes:
> Daniel Rall wrote:
>
>>
>> A method which I've been tossing around to deal with this is to use a
>> ReferenceInsertionEventHandler:
>>
>> http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20and%20Event%20Handlers
>>
>> $inner_content has a handle to some sort of processing mechanism which
>> is triggered (tested for using instanceof) by the
>> ReferenceInsertionEventHandler configured for your EventCartridge.
>> The triggered code writes to the same output stream which the Writer
>> you passed to mergeTemplate() uses.
>
> Why can't $inner_content just render the template to the same stream as
> the outer_template is being written to. In this case
> $inner_content.toString() would just return null or "" and the template
> would be written to the stream when the toString() method was called.
> This is not a proper use of the toString() method, it would probably be
> better to have a better method name (e.g. render). In t3, there is a
> Renderer (DirectRenderer) that writes directly to the stream and it is
> used in layout templates to render navigations, screens, or portlets (or
> whatever else you want to call the inner templates).
>
> What does a ReferenceInsertionEventHandler add to this? What am I
> misunderstanding?
ReferenceInsertionEventHandler allows you to have a render()-esque
method (which is called by your handler). toString() returns "", and
you escape the alluring trap of having toString() call render()
directly (which would be an improper overloading of the toString()
method, breaking the contract defined by java.lang.Object).
Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by John McNally <jm...@collab.net>.
Daniel Rall wrote:
>
> A method which I've been tossing around to deal with this is to use a
> ReferenceInsertionEventHandler:
>
> http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20and%20Event%20Handlers
>
> $inner_content has a handle to some sort of processing mechanism which
> is triggered (tested for using instanceof) by the
> ReferenceInsertionEventHandler configured for your EventCartridge.
> The triggered code writes to the same output stream which the Writer
> you passed to mergeTemplate() uses.
>
Why can't $inner_content just render the template to the same stream as
the outer_template is being written to. In this case
$inner_content.toString() would just return null or "" and the template
would be written to the stream when the toString() method was called.
This is not a proper use of the toString() method, it would probably be
better to have a better method name (e.g. render). In t3, there is a
Renderer (DirectRenderer) that writes directly to the stream and it is
used in layout templates to render navigations, screens, or portlets (or
whatever else you want to call the inner templates).
What does a ReferenceInsertionEventHandler add to this? What am I
misunderstanding?
john mcnally
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gary Bisaga" <ga...@maximus.com> writes:
>>Velocity streams data directly using the Writer it was provided with.
>>One the AST is built, static content needs no further memory allocated
>>for it.
>
> I'm pretty much a newbie to Turbine so I'm not sure whether this answers my
> question. Perhaps it does; but in my understanding of how this all works,
> say I am doing these operations:
>
> 1. First process the "inner" section's template (e.g. the Jetspeed portlet)
> by calling mergeTemplate( String templateName, Context context, Writer
> writer ). The Writer presumably is something like a CharacterArrayWriter. It
> can't go directly out to the browser because in step 3 below I want to
> include this content in the middle of the "outer" template's content.
>
> 2. Somehow get the data in the CharacterArrayWriter into the context. I
> think this is necessary because I want to, in my "outer" section's template,
> to refer to the inner section's data. The "outer" template would then look
> something like this:
>
> <TABLE><TR><TD>$inner_content</TD></TR></TABLE>
>
> 3. This requires Velocity, on the second call to mergeTemplate, to convert
> the data from each "inner" CharacterArrayWriter into a String so it can
> stream it out to the "outer" Writer, which involves an extra copy of each
> "inner" string value, which is what I am trying to avoid. These copies (I
> believe) include what you refer to as "static content."
Using a buffer for the "body" content is something that's often done
by Velocity users. However, it's a fairly inefficient usage of an
efficient engine (especially if your application does not pool the
buffers).
A method which I've been tossing around to deal with this is to use a
ReferenceInsertionEventHandler:
http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20and%20Event%20Handlers
$inner_content has a handle to some sort of processing mechanism which
is triggered (tested for using instanceof) by the
ReferenceInsertionEventHandler configured for your EventCartridge.
The triggered code writes to the same output stream which the Writer
you passed to mergeTemplate() uses.
> If I'm not mistaken (please correct me if I am wrong) this is
> exactly what Jetspeed does: for example the multicolumn-customize.vm
> template says:
This is the Turbine User list, not the Jetspeed list. Please direct
your Jetspeed questions to jetspeed-user@jakarta.apache.org.
- Daniel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: VM Templates vs JSP, How does everyone find VM speed
Posted by Gary Bisaga <ga...@maximus.com>.
>Velocity streams data directly using the Writer it was provided with.
>One the AST is built, static content needs no further memory allocated
>for it.
I'm pretty much a newbie to Turbine so I'm not sure whether this answers my
question. Perhaps it does; but in my understanding of how this all works,
say I am doing these operations:
1. First process the "inner" section's template (e.g. the Jetspeed portlet)
by calling mergeTemplate( String templateName, Context context, Writer
writer ). The Writer presumably is something like a CharacterArrayWriter. It
can't go directly out to the browser because in step 3 below I want to
include this content in the middle of the "outer" template's content.
2. Somehow get the data in the CharacterArrayWriter into the context. I
think this is necessary because I want to, in my "outer" section's template,
to refer to the inner section's data. The "outer" template would then look
something like this:
<TABLE><TR><TD>$inner_content</TD></TR></TABLE>
3. This requires Velocity, on the second call to mergeTemplate, to convert
the data from each "inner" CharacterArrayWriter into a String so it can
stream it out to the "outer" Writer, which involves an extra copy of each
"inner" string value, which is what I am trying to avoid. These copies (I
believe) include what you refer to as "static content."
Now, an alternative implementation would be to do everything in a "pull"
model, which would get around the multiple copy problem. But I dislike this
because it requires the "outer" template writer to have full knowledge of
the contents of each of the sections inside. I'd rather just have the outer
section writer be able to use some kind of generic reference (like
$inner_content above) and have the system be able to deal with what exactly
is in that "inner" section (and it's not in Java code, there is a registry
to tell the system this information). If I'm not mistaken (please correct me
if I am wrong) this is exactly what Jetspeed does: for example the
multicolumn-customize.vm template says:
<table border="0" cellpadding="2" cellspacing="0" width="100%">
<tr>
#set ($col = 0)
#foreach ( $column in $portlets )
...
#end
</tr></table>
which is essentially what I want to do.
Thanks for your consideration.
<>< gary
-----Original Message-----
From: dlr@despot.finemaltcoding.com
[mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
Sent: Thursday, February 21, 2002 12:29 PM
To: Turbine Users List
Subject: Re: VM Templates vs JSP, How does everyone find VM speed
"Gary Bisaga" <ga...@maximus.com> writes:
> I don't know, but I have been wondering about the same issue. In
particular:
> in our application the displayed web page is made up of nested "sections",
> each of which has its own template. Sort of like jetspeed does it, with
the
> portlets, controls, and controllers.
>
> This means that there's an awful lot of string copying going on, as you
> collect the results from the innermost template, include that in the
> next-outer template, and so on. One specific thing I was wondering is
> whether there is any support for using a scatter/gather kind of operation
in
> Velocity, where you have a structure like this:
>
> public class ScatterGatherObject {
> // Each one of the objects in this list can either be (a) a String or
> // (b) another ScatterGatherObject.
> ArrayList subObjects;
> public String toString () { ... }
> }
>
> Velocity could, at each template stage, produce one of these objects
instead
> of a String. The values you put in the context could be either Strings or
> ScatterGatherObjects; in the latter case, the new ScatterGatherObject
would
> simply get a reference to the old one. Finally, at the end of processing,
> the toString method would go depth-first through all the
> ScatterGatherObjects and concatenate all the Strings in one big
> StringBuffer. It seems to me that this could potentially eliminate a hugh
> amount of string copying.
>
> Any thoughts?
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gary Bisaga" <ga...@maximus.com> writes:
> I don't know, but I have been wondering about the same issue. In particular:
> in our application the displayed web page is made up of nested "sections",
> each of which has its own template. Sort of like jetspeed does it, with the
> portlets, controls, and controllers.
>
> This means that there's an awful lot of string copying going on, as you
> collect the results from the innermost template, include that in the
> next-outer template, and so on. One specific thing I was wondering is
> whether there is any support for using a scatter/gather kind of operation in
> Velocity, where you have a structure like this:
>
> public class ScatterGatherObject {
> // Each one of the objects in this list can either be (a) a String or
> // (b) another ScatterGatherObject.
> ArrayList subObjects;
> public String toString () { ... }
> }
>
> Velocity could, at each template stage, produce one of these objects instead
> of a String. The values you put in the context could be either Strings or
> ScatterGatherObjects; in the latter case, the new ScatterGatherObject would
> simply get a reference to the old one. Finally, at the end of processing,
> the toString method would go depth-first through all the
> ScatterGatherObjects and concatenate all the Strings in one big
> StringBuffer. It seems to me that this could potentially eliminate a hugh
> amount of string copying.
>
> Any thoughts?
Velocity streams data directly using the Writer it was provided with.
One the AST is built, static content needs no further memory allocated
for it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: VM Templates vs JSP, How does everyone find VM speed
Posted by Gary Bisaga <ga...@maximus.com>.
I don't know, but I have been wondering about the same issue. In particular:
in our application the displayed web page is made up of nested "sections",
each of which has its own template. Sort of like jetspeed does it, with the
portlets, controls, and controllers.
This means that there's an awful lot of string copying going on, as you
collect the results from the innermost template, include that in the
next-outer template, and so on. One specific thing I was wondering is
whether there is any support for using a scatter/gather kind of operation in
Velocity, where you have a structure like this:
public class ScatterGatherObject {
// Each one of the objects in this list can either be (a) a String or
// (b) another ScatterGatherObject.
ArrayList subObjects;
public String toString () { ... }
}
Velocity could, at each template stage, produce one of these objects instead
of a String. The values you put in the context could be either Strings or
ScatterGatherObjects; in the latter case, the new ScatterGatherObject would
simply get a reference to the old one. Finally, at the end of processing,
the toString method would go depth-first through all the
ScatterGatherObjects and concatenate all the Strings in one big
StringBuffer. It seems to me that this could potentially eliminate a hugh
amount of string copying.
Any thoughts?
<>< gary
-----Original Message-----
From: Burian, Todd [mailto:tburian@interactapps.com]
Sent: Thursday, February 21, 2002 11:50 AM
To: turbine-user@jakarta.apache.org
Subject: VM Templates vs JSP, How does everyone find VM speed
Our compan is planning to migrate from jsp to Turbine/Velocity. I have
noticed a few issues where it seems Velocity is slower tha JSP and it seems
slower in general. What do all you gurus think?
W. Todd Burian
Senior Java Developer
317-658-5600
<http://www.interactapps.com/> interactapps.com
tburian@lldc.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Luke Holden <al...@prodigy.net>.
Turning on caching makes a huge speed difference too.
As far as application servers go... I find resin to be one of the fastest out
there. Resin + caching in turbine makes for a very very quick application.
(Actually I have very little load time with caching off... but that is only
for single page views... when you scale that up to so many hits per min
having caching on helps a lot.)
On Thursday 21 February 2002 09:14 am, you wrote:
> Odd, I have always found Turbine/Velocity to be much faster than JSP but I
> guess it depends on the app server.
>
> > -----Original Message-----
> > From: Burian, Todd [mailto:tburian@interactapps.com]
> > Sent: 21 February 2002 16:50
> > To: turbine-user@jakarta.apache.org
> > Subject: VM Templates vs JSP, How does everyone find VM speed
> >
> >
> > Our compan is planning to migrate from jsp to Turbine/Velocity.
> > I have noticed a few issues where it seems Velocity is slower tha
> > JSP and it seems slower in general. What do all you gurus think?
> >
> > W. Todd Burian
> > Senior Java Developer
> > 317-658-5600
> > <http://www.interactapps.com/> interactapps.com
> > tburian@lldc.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VM Templates vs JSP, How does everyone find VM speed
Posted by Daniel Rall <dl...@finemaltcoding.com>.
It also depends on the Writer that you supply Velocity with.
"Gareth Coltman" <ga...@majorband.co.uk> writes:
> Odd, I have always found Turbine/Velocity to be much faster than JSP but I
> guess it depends on the app server.
>
>> -----Original Message-----
>> From: Burian, Todd [mailto:tburian@interactapps.com]
>> Sent: 21 February 2002 16:50
>> To: turbine-user@jakarta.apache.org
>> Subject: VM Templates vs JSP, How does everyone find VM speed
>>
>>
>> Our compan is planning to migrate from jsp to Turbine/Velocity.
>> I have noticed a few issues where it seems Velocity is slower tha
>> JSP and it seems slower in general. What do all you gurus think?
>>
>> W. Todd Burian
>> Senior Java Developer
>> 317-658-5600
>> <http://www.interactapps.com/> interactapps.com
>> tburian@lldc.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: VM Templates vs JSP, How does everyone find VM speed
Posted by Gareth Coltman <ga...@majorband.co.uk>.
Odd, I have always found Turbine/Velocity to be much faster than JSP but I
guess it depends on the app server.
> -----Original Message-----
> From: Burian, Todd [mailto:tburian@interactapps.com]
> Sent: 21 February 2002 16:50
> To: turbine-user@jakarta.apache.org
> Subject: VM Templates vs JSP, How does everyone find VM speed
>
>
> Our compan is planning to migrate from jsp to Turbine/Velocity.
> I have noticed a few issues where it seems Velocity is slower tha
> JSP and it seems slower in general. What do all you gurus think?
>
> W. Todd Burian
> Senior Java Developer
> 317-658-5600
> <http://www.interactapps.com/> interactapps.com
> tburian@lldc.net
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>