Use StringBuilder instead of String concat for startup code

[geoand]

Unfortunately the JDK's indyfied String concatenation has a slight performance penalty at startup, so for code we know will always be run at startup, let's not pay that unnecessary price

For this to have an effect, we would also need smallrye/smallrye-config#1292.

@franz1981 @radcortez I don't really know how I feel about this one. On one hand it does make a difference as the following before and after flamegraphs show:

before

after

but on the other hand:

• The code is much uglier
• The can turn into a continuous Whac-A-Mole

[gsmet]

I would try to see if we can get most of the improvement without specifying the length. For me it's what makes things ugly (and cumbersome to maintain). The rest is quite straightforward.

Now, I do agree on the continuous Whac-A-Mole but on the other side, there's not many of us adjusting this code so if we're all on the same page, it should be (mostly?) fine?

[geoand]

I would try to see if we can get most of the improvement without specifying the length

We would indeed, I just felt like going the extra small step 🙂

Now, I do agree on the continuous Whac-A-Mole but on the other side, there's not many of us adjusting this code so if we're all on the same page, it should be (mostly?) fine?

I do agree with this, which I why I started doing the work 🙂

[punkratz312]

is this kind of related?

#45592

[geoand]

@dmlloyd pointed out a better way to do this: #45647

[dmlloyd]

The risk is that individual call sites might be faster on a one time or initial basis, but the amortized cost might be greater in the end if we apply this change broadly.

[geoand]

That's why I only did it for the core module where the classes should pretty much be used at startup, as opposed to extensions which could be handling concats where throughput matters