optimize uri parsing to reduce StringBuilder allocations

[fwbrasil]

Problem

The uri parsing has a high allocation rate of StringBuilder objects in ArrayView.mkStringOpt. The parsing happens on each incoming request and the implementation of mkStringOpt uses a large StringBuilder initialized with 128 chars. The actual strings are typically much smaller representing a single path element.

Solution

I've debugged the code and noticed that the vast majority of calls have a valueTs with a single path element. I've added a special case for it so mkStringOpt can be avoided.

Notes

• This is part of Reduce allocation rate tapir#3552.
• It's probably better to avoid the custom initial StringBuilder capacity in mkStringOpt since the strings seem generally small and growing the buffer is typically not too expensive. I can follow up on that if you like.
• Another alternative is optimizing the code that uses mkStringOpt.

[adamw]

@kciesielski that's exactly the scenario we've been talking about today: Uri parsing that has a single string component.

as a follow-up, I think it might be good to (create an issue, as a start) to take a look at the interpolation cases, where we have a couple of string components - allocating the large StringBuilder is likely to be a bottleneck there as well

[adamw]

maybe add a comment here why the optimization is in place? with the issue number

[fwbrasil]

sure! I've just added it

[kciesielski]

Nice, it could help to resolve expensive Uri parsing in softwaremill/tapir#3547 and softwaremill/tapir#3550. I'll build this locally and see if it reduces overhead in the performance tests.

[kciesielski]

Update: An improvement is visible when profiling performance tests with the DefaultServerLog interceptor enabled.
Frame: NettyServerRequest.uri
Without optimization: CPU: 6.81% samples / 12.44% allocations
With optimization: CPU 5.45% samples / 11.68% allocations