Add frame count to pprof message attributes

[laurit]

Profiling team requests that pprof messages should be accompanied by the number of stack frames (non-unique) represented in the pprof.
@gsmirnov-splk please review

[Kielek]

What's about already released implementation without this parameter? Will it be handled correctly?

[gsmirnov-splk]

LGTM, thanks

[gsmirnov-splk]

What's about already released implementation without this parameter? Will it be handled correctly?

@Kielek yes, we will still support agents that do not report this attribute. No hard date on how long, but my gut feeling suggests that at least for a year.

[Kielek]

@gsmirnov-splk, I suppose you should support as long as we support any already released library.
Breaking it could break environment for our customers.
I am fine with adding new attribute as long as you agreed deprecation date with PMs.

[pellared]

@Kielek please let us know if you want this PR to be merged after the 1.5.0 release (#193)

[pellared]

@seemk Can you please take a look as well?

[akubik-splunk]

Per discussion with @gsmirnov-splk the messages without support will continue to be supported by backend for at lest 12 months from now. Additional recommendations for release tagging will be made to indicate releases deprecated and no longer supported

[seemk]

Node.js already does sample coalescing, i.e. in memory profiling we multiply the sample count with allocation size per sample. Does this mean the total number reported here should be the amount of samples before this multiplication?

[laurit]

Node.js already does sample coalescing, i.e. in memory profiling we multiply the sample count with allocation size per sample. Does this mean the total number reported here should be the amount of samples before this multiplication?

My understanding is that this is used to estimate pprof data size, so it should be the number after coalescing.

[gsmirnov-splk]

@seemk The backend limiting factor is the number of (non-unique) frames coming from all the stack traces. If you coalesce 10 stack traces into one (such that when we read the pprof, we read one sample instead of 10), then this attribute should be after coalescing. If it is still 10 sample-s recorded in the pprof, then it should be before the coalescing.

[seemk]

@seemk The backend limiting factor is the number of (non-unique) frames coming from all the stack traces. If you coalesce 10 stack traces into one (such that when we read the pprof, we read one sample instead of 10), then this attribute should be after coalescing. If it is still 10 sample-s recorded in the pprof, then it should be before the coalescing.

Thanks!