That's very odd and slightly disconcerting that that code came from a
file named 1.2. Looking at the version history, the response's output
stream hasn't been the default since 1.0:
http://svn.apache.org/viewvc/velocity/tools/tags/VELTOOLS_1_2_FINAL/src/java/org/apache/velocity/tools/view/servlet/VelocityViewServlet.java?revision=333023&view=markup
http://svn.apache.org/viewvc/velocity/tools/tags/VELTOOLS_1_1_FINAL/src/java/org/apache/velocity/tools/view/servlet/VelocityViewServlet.java?revision=72063&view=markup
http://svn.apache.org/viewvc/velocity/tools/tags/VELTOOLS_1_0/src/java/org/apache/velocity/tools/view/servlet/VelocityViewServlet.java?revision=71717&view=markup
Anyway, short of profiling the app or having a good idea of it's needs
and the hardware (and software) running it, it is very hard to say
what is faster or better with much confidence. Here's what i can tell
you:
- the VVS uses VelocityWriters because the old VelocityServlet did.
basically, when i wrote it, i trusted that the VelocityWriter was used
for good reason and left that decision intact. so far, it has not
been a problem for us.
- the VelocityWriters are also pooled due to the same logic. i'm not
aware of any problems with this either, however, it was a decision
made back when object instantiation was a more expensive op. modern
JVMs have sped this up dramatically. i can't say without profiling
(which i'm not very motivated or equipped to do myself), but it may be
that pooling these (even with such a simple pool impl) is now slower
than creating them on the fly.
- in any servlet-handled HTTP request, there is a LOT that happens. i
strongly recommend that you profile your app before you bother trying
to optimize things. performance can vary so very dramatically due to
different hardware, JVMs, servlet engines, and more, that it is almost
never worth the effort to optimize small things like this without
first having good evidence that it is a significant bottleneck, memory
hog, or whatever. premature optimization is a classic and common
waste of time.
if you really need more speed or less memory use, then your best bet
is probably to start by profiling your app.
so, yeah... i hope this helps, even if it's not the answer you're
looking for... :)
On 1/4/07, John <[EMAIL PROTECTED]> wrote:
I got it from the VelocityViewServlet in velocity-tools-1.2-src.zip. I guess
the basic question was - short of profiling the app - is one method faster
and/or better than the other? It would seem to me like the pooled
VelocityWriters are the way to go?
John
On 1/4/07, Nathan Bubna <[EMAIL PROTECTED]> wrote:
>
> What version of the VelocityViewServlet are you taking that code from?
> It hasn't looked that way in some time. I'd recommend taking a look
> at a more recent version of the VelocityViewServlet's code to begin.
> Beyond that, i can't really tell whether it is better for your
> application to do what VVS currently does (wrapping the response
> writer with pooled VelocityWriters) or to just directly use the
> response's writer. If you are concerned about it, then you should
> test the performance of both and choose which works best for your
> application.
>
> On 1/4/07, John <[EMAIL PROTECTED]> wrote:
> > This may be a newbie question, but I'm trying to figure out which of the
> > following two methods is better for performing the template merge and
> > outputting it in a servlet?
> >
> > Using the HttpServletResponse's Writer object?
> >
> > Writer writer = response().getWriter();
> > template.merge(context, writer);
> > writer.close();
> >
> > OR
> >
> > the VelocityViewServlet way with the WriterPool and VelocityWriter?
> >
> > vw = (VelocityWriter) writerPool.get();
> >
> > if (vw == null)
> > {
> > vw = new VelocityWriter( new OutputStreamWriter(output,
> > encoding), 4*1024, true);
> > }
> > else
> > {
> > vw.recycle(new OutputStreamWriter(output, encoding));
> > }
> >
> > template.merge( context, vw);
> >
> >
> >
> > Thanks
> > John
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
