perf(prof): pre-reserve function name buffer

[morrisonlevi]

PROF-12543

Description

When a function name isn't cached, we calculate the function name which has up to 5 "segments":

{$module_name}|{$class_name}::{$method_name}

And with how the code was written, we were doing potentially 5 memory allocations per function name. Of course, the Vec's growth amortization prevented some of these, but not all of them.

This now pre-reserves the size of the function name buffer.

Motivation

Here's the before/after with the whole-host profiler:

The "key" bit is shaving off ~8ms of the ~24ms operation, across a minute. Obviously this is a tiny gain but it is also very easy. It's a good practice to right-size your strings/buffers when you know how larger they are ahead of time.

The function cache is reset at the start of each request, so at the start of each request the samples tend to have more uncached function names than ones which happen later on. Coupled with the fact that we are walking the stack on-thread, the code is reasonably hot early on when collecting a sample.

Additional Notes

Today I was able to look at the whole-host profiler's data for the PHP profiler running on the enterprise DOE app that Florian has set up, and I noticed the memory being reallocated in the data.

I have used ddprof before on the PHP profiler, even recently. I believed I saw this recently with ddprof, but it had a larger impact when measured by the whole host profiler. I have no idea which is more accurate, or if we are simply dealing with the fact that we're sampling something that by design happens infrequently, and just got different results accordingly.

Reviewer checklist

• Test coverage seems ok.
• Appropriate labels assigned.