"Total samples" as milliseconds is confusing about pprof

[bcmills]

Rewording would help a little, but it's still confusing: if you say "Samples account for 14.50ms", how do you know the duration of each of those samples?

What does it mean to say the samples "account for 14.50ms" on a 2.5GHz CPU with 4-wide instruction dispatch (as is typical for modern AMD64 implementations)? Does that mean that the sampled instructions were the most recently dispatched instruction for each of 36,250,000 clock cycles? Does it mean that the instructions saturated the ALU for that many clock cycles? Something else entirely?

When you're dealing with a sample-based system, it's meaningful to talk about total times and fractions of the total sample. Fractions of the total time are nonsensical: it's like choosing 10 points along a 1-meter line and claiming that those points account for three centimeters of the line.

[rauls5382]

Each callstack in a profile is associated to a set of values. What is reported here is the sum of these values for all the callstacks in the profile, and is useful to understand the weight of individual frames over the full profile.

profile.proto is an unsampled format, so we in general do not have access to the number of samples collected.

[bcmills]

My point is that the "sum" is the sum of a discrete number (a quantity of samples), not a continuous range (a time interval). Reporting the sums makes perfect sense, but reporting discrete numbers using continuous units is just plain confusing.

[bcmills]

Or, to put it a different way: even if we don't have access to the number of samples, we should report the quantities in some unit that doesn't (erroneously) suggest continuity.

[rauls5382]

We're reporting the sum using the unit described in the profile.
Would you have a concrete suggestion for this example? Maybe just a rewording would help, like:

Duration: 1.60s, Samples account for 14.50ms (0.9%)