I'm doing a lot of benchmarks and I just discovered this code in the Lucee project.

private static final int BUFFER_SIZE = 100000;
private StringBuilder buffer = new StringBuilder(BUFFER_SIZE);

https://github.com/lucee/Lucee/blob/6.0/core/src/main/java/lucee/runtime/writer/CFMLWriterImpl.java

I found a significant performance boost changing it to 0 when doing my load testing. Consider that some function bodies that have no output and thus are wasting 100,000 bytes on each new pagecontext object for no reason.

It appears to make a very drastic improvement in my new feature. I am using JDK 17 build for Project Loom virtual threads and have implemented this as new lucee CFML functions as well as to run CFML requests and it is working great. I get performance that is nearly 100% faster just changing the BUFFER_SIZE to zero. I found this in the process of trying to find the "least work" approach to creating the PageContextImpl for the virtual thread since the creation of PageContext is way too many operations as it was and I don't need all of the behavior of cfthread. I was able to trim out a lot of other things in my fork and still retain thread safety in local scope and body output which are the most important things. I was able to achieve initially 400% better performance with virtual thread compared to regular thread, but then it became about 700% to 800% faster after changing this value. Consistently 500% to 800% faster parallel CFML snippets will be possible with the new InvokeDynamic based feature Thread.startVirtualThread, very cool.

Posted more thoughts here: