You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Szegedi Attila <sz...@freemail.hu> on 2001/08/01 13:06:52 UTC

[PATCH] Increasing throughput of text nodes

I have a pet peeve when it comes to template engines: I always take a look
at whether text nodes use String or char[] to store the text of the text
node. Usually they use String - and it's wrong because when it's output
through the Writer, the Writer will call getChars() on the String to obtain
a char[] and then write out the char[]. If the node stored char[] instead of
String in its text node, we would avoid the performance penalty of executing
Writer.write(String) instead of Writer.write(char[]) - which is an
additional "System.arraycopy()" (as well as a "new char[]" if
String.length()>1024).

Altough this is a small and trivial optimization, it comes at no cost and
spares both time and memory which can make a difference in throughput of a
heavy-loaded environment.

Attached is a diff -u patch for
org.apache.velocity.runtime.parser.node.ASTText that switches its internal
storage from String to char[].

Attila.


RE: [PATCH] Increasing throughput of text nodes

Posted by David Rees <dr...@ebetinc.com>.
> -----Original Message-----
> From: Szegedi Attila [mailto:szegedia@freemail.hu]
>
> I have a pet peeve when it comes to template engines: I always take a look
> at whether text nodes use String or char[] to store the text of the text
> node. Usually they use String - and it's wrong because when it's output
> through the Writer, the Writer will call getChars() on the String
> to obtain
> a char[] and then write out the char[]. If the node stored char[]
> instead of
> String in its text node, we would avoid the performance penalty
> of executing
> Writer.write(String) instead of Writer.write(char[]) - which is an
> additional "System.arraycopy()" (as well as a "new char[]" if
> String.length()>1024).
>
> Altough this is a small and trivial optimization, it comes at no cost and
> spares both time and memory which can make a difference in throughput of a
> heavy-loaded environment.

Cool!  Got any benchmarks to show that it's faster if at all?

Speaking of which, is there any sort of standard benchmark suite to run
velocity through so that people can easily check improvements like this
since performance is very important to a lot of people using Velocity.

I seem to remember seeing something like this inside of the Velocity
sources, but I can't find it now...

-Dave