@retronym want to test this out on the customer codebase...?

Some context -- this method is called indirectly by Zinc's Extract API phase to generate its representation of annotations.

The last commit is, "pre-construct with string add to enclose in quotes" then "expand where necessary using replace".

That optimizes for the common case, where the hit for expansion (escaping) is array copy (which only sounds bad).

The savings is the append per char (which is bad).

The assumption is that the pre-construction is optimal, so it relies on the platform.

I'd like @retronym guess about the last commit and comment. I didn't write a test to estimate what ratio of escapes would make it less desirable, but maybe annotations have fewer of them.

The other choice is prescan for escapable chars; then only strings with escapes must suffer construction costs. Maybe I'll add that while we're waiting.

Actually I saw retronym doing thyme timings at c3fcd4e and felt bad for being lazy, so I will try to measure if this is useful.

I was at that commit because while exercising -Wnonunit-statement, I noticed the use of StringBuffer instead of StringBuilder. It was like a blast from the past.

@lrytz squashed, rebased, unwound experiment using replace (I haven't tested performance yet), added pre-check for whether there are escapes to expand.

Probably the ticket doesn't require extreme performance.

Using string concat (stradd) by default assumes that, while we must be JDK 8 compat, hopefully it's using modern intrinsic for adding quote chars, which I assume to be array copy of underlying chars. However, also untested.

[info] Benchmark                   Mode  Cnt      Score     Error  Units
[info] ConstantBenchmark.measure   avgt   40  14007.372 ± 176.270  ns/op
[info] ConstantBenchmark.measure0  avgt   40  32518.810 ± 318.486  ns/op

I tested by moving the SymbolTable4Testing from junit to testkit. I'll PR that in case of utility.

You were wise to merge before I benched the replace version.

Small improvement by sizing a string builder for simple wrapping in quotes:

[info] ConstantBenchmark.measure  avgt   40  13924.241 ± 96.251  ns/op

This is with a 3000 char string, so probably it allocates a big array plus margin when appending; maybe it must arraycopy on toString; is there no arraycopy if exactly sized?

Thank you for the benchmark!

is there no arraycopy if exactly sized?

There must be a copy, the StringBuilder can continue to be used. Unless they do something fancy, like a dirty bit in the string builder and lazy array copy, but I didn't see anything like that.