Re: Limiting VelocityLayoutServlet buffer size

[Nathan Bubna <nb...@gmail.com>]

On Fri, Dec 18, 2020 at 3:01 PM Christopher Schultz <
chris@christopherschultz.net> wrote:

> Nathan,
>
> On 12/16/20 12:43, Nathan Bubna wrote:
> > In general, i think the overhead from StringWriter is probably pretty
> minimal.
> >
> > Before worrying about it, I'd want to see some profiling that showed  it
> was a problem.
>
...

> In Java 8, StringBuilder wins by a factor of 10. In Java 15, it's a
> factor of ~20.
>
...

That's impressive.



> The question is whether or not it will make a difference when using a
> StringWriter
> versus a proposed StringBuilderWriter when the thing that's likely to
> take the most time is the many re-sizes of the internal char[] array
> that both use.
>

Yup. Impressive gains in a focused area don't give the full picture.

...

> Perhaps starting with a larger-than-default buffer for those will also
> help. (The default size of a StringWriter -- which is what
> VelocityLayoutServlet uses - is a mere 16 characters). I find it
> unlikely that such a small buffer would be practical for most Velocity
> workloads. Maybe we can improve performance a bit by specifying a larger
> default buffer/builder size to avoid some of the initial buffer-resizes
> that will inevitably occur.
>

Heh. I didn't realize StringWriter was so small by default. Sounds like a
promising optimization. 16 chars is obviously ludicrously small for
templating.

> Our dev resources these days are limited and things are pretty
> > stable, so i'm wary of taking on optimizations that increase our
> > complexity.
>

Honestly, the changes you are talking about are not that complex. I'm just
overwhelmed. This seems overcautious of me to bother saying in hindsight.
But you can probably see by how long i've let Velocity emails languish that
i just don't have useful amounts of time for it myself.