[Profiling] Improve performance of frame group operations for the flamegraph and Top N functions APIs

[jbcrail]

Part of https://github.com/elastic/prodfiler/issues/2479

This PR refactors the internal data structure used to group stack frames so that the performance of the flamegraph and Top N function APIs is improved.

This PR also has smaller updates:

• moved frame groups methods into separate file
• renamed defaultGroupBy to createFrameGroup
• renamed hashFrameGroup to createFrameGroupID

Background

I profiled the flamegraph and TopN function endpoints and narrowed in on hashFrameGroup as a costly function. For background, hashFrameGroup is responsible for creating a serialized representation of a stackframe so that sibling frames can be grouped together. According to local measurements, hashFrameGroup is called about ~260k times per request and this value is consistent across different time ranges.

The original implementation for hashFrameGroup used JSON.stringify, but the latest implementation uses jsonStableStringify to obtain deterministic results. I experimented with a new implementation using an interface for each specific frame group combined with string concatenation (see subclass+concat in the charts below). This new implementation has the same deterministic properties as jsonStableStringify.

Each implementation was measured several times and the average of each respective metric was taken. The charts below show the preliminary results for the optimized implementation.

Cumulative time spent in hashFrameGroup for one request

Request latency for one request

[dgieselaar]

@jbcrail this will probably conflict with some of my changes wrt differential flamegraph, do you mind holding off merging until we figure out what the best order is to get this on?

[kibana-ci]

:green_heart: Build Succeeded

• Buildkite Build
• Commit: 128e3a73528ad07040383f462d9b1f739b6171b8

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
profiling	98	95	-3

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
profiling	262.3KB	257.8KB	-4.5KB

History

• :green_heart: Build #65279 succeeded 84c164b277ebb47537a089b370383a03adefd2a6
• :broken_heart: Build #64425 failed 46939ee4eb6226ffc6eb7726b5ec395784104318
• :broken_heart: Build #64417 failed 40af216f8c4c87d29f2ecf013d2c85bb6555a95b
• :broken_heart: Build #64126 failed 756a7a6c3a97750ade227f6cfd4dd55b39fc3c5e
• :broken_heart: Build #64125 failed ef7155393cab8c833d352475aa83ca2c12adc98e

To update your PR or re-run it, just comment with: @elasticmachine merge upstream