Performance regression when using Handlebars with large documents in 4.3.1 release (cause: memory re-allocation behavior change in commons text 10) about handlebars.java HOT 4 OPEN

Quick addition to @aschwarte10 's comment above: the good results for the Java StringWriter are with JDK 17. There have been some changes between e.g. JDK 11 and 17 there, so the performance of the plain StringWriter might depend on the underlying Java version...

from handlebars.java.

I think we may be seeing something similar... we've got a large template (4MB).

In a docker container running in Docker Desktop on my box, rendering it precompiled takes > 2,000 milliseconds.

On the same box but running the JVM outside docker, rendering it precompiled takes < 30 milliseconds.

Handlebars 4.3.1

Docker env:

openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment (build 17.0.7+7-alpine-r1)
OpenJDK 64-Bit Server VM (build 17.0.7+7-alpine-r1, mixed mode, sharing)

I'm surprised that it can be 2 orders of magnitude difference between in and out of a docker container... but taking a JFR recording it does look like a lot of the time is spent in reallocate:

java.util.Arrays.copyOf(Arrays.java:3633)
  at org.apache.commons.text.TextStringBuilder.reallocate(TextStringBuilder.java:2610)
  at org.apache.commons.text.TextStringBuilder.ensureCapacity(TextStringBuilder.java:1829)
  at org.apache.commons.text.TextStringBuilder.append(TextStringBuilder.java:646)
  at org.apache.commons.text.TextStringBuilder.append(TextStringBuilder.java:619)
  at org.apache.commons.text.TextStringBuilder.append(TextStringBuilder.java:531)
  at com.github.jknack.handlebars.internal.FastStringWriter.append(FastStringWriter.java:55)
  at com.github.jknack.handlebars.internal.Variable.merge(Variable.java:148)
  at com.github.jknack.handlebars.internal.BaseTemplate.apply(BaseTemplate.java:126)
  at com.github.jknack.handlebars.internal.TemplateList.merge(TemplateList.java:95)
  at com.github.jknack.handlebars.internal.BaseTemplate.apply(BaseTemplate.java:126)
  at com.github.jknack.handlebars.internal.BaseTemplate.apply(BaseTemplate.java:114)
  at com.github.jknack.handlebars.internal.ForwardingTemplate.apply(ForwardingTemplate.java:100)

from handlebars.java.

I'm an idiot, I wasn't actually evaluating the template locally - when I did it had similar performance characteristics to the behaviour in Docker.

The issue is that the buffer char[] is only 1,600 characters by default, and as you evaluate a template it only increases by the amount you can append to it each time. In our case we end up with a 4,000,000 chars, and it mostly increments by 10 to 50 characters, so we literally copy the data tens of thousands of times.

I can "fix" it by setting the system property -Dhbs.buffer=4200000 - but allocating a 4MB buffer for every template seems very wasteful when most are much much smaller. If the buffer doubled each time it was too small that might be a better solution? Or if it used the template size as a starting point?

from handlebars.java.

I've raised #1066 as a suggested fix for this

from handlebars.java.