`tracing-flame` output cannot be used as-is to generate a valid flamechart or flamegraph

[BatmanAoD]

Bug Report

Version

(all, but here is my current set of tracing dependencies)

tracing v0.1.41
tracing-attributes v0.1.30
tracing-core v0.1.34
tracing-error v0.2.0
tracing-flame v0.2.0
tracing-log v0.2.0
tracing-opentelemetry v0.24.0
tracing-opentelemetry v0.28.0
tracing-opentelemetry v0.29.0
tracing-serde v0.2.0
tracing-subscriber v0.3.20
tracing-test v0.2.5
tracing-test-macro v0.2.5

Platform

(all; this is a consequence of a documented design choice)

Crates

tracing-flame

Description

tracing-flame specifies in its documentation:

Because tracing-flame doesn’t use sampling, the number at the end of each folded stack trace does not represent a number of samples of that stack. Instead, the numbers on each line are the number of nanoseconds since the last event in the same thread.

I don't see any command-line option in inferno-flamegraph to change how the sample-count is interpreted, and I'm not aware of any other tool that interprets the number at the end of each line in this way.

Consequently, the flamegraphs and flamecharts I'm able to generate with the data produced by tracing-flame appears to be dominated by functions that happen to have high "time since last event" values. I would expect that this would be inversely correlated with high sample counts, and indeed, in my testing, that appears to be the case. So the flamegraphs are essentially "inverted", with the most frequently-called functions taking up the least space (and often being deleted, which may explain #2537).

(Note that I am using "inverted" in a different sense than it's used in #1534, where it's referring to the flamechart being in reverse chronological order.)

[BatmanAoD]

I believe that simply replacing the nanoseconds value with 1 on all lines enables generating a valid flamegraph.