Support arbitrary scaling factor

[jonhoo]

The --factor option in flamegraph.pl lets you arbitrarily multiply all sample counts by a constant, probably to show "true counts" if you've undersampled. We should document and adopt that option.

[jasonrhansen]

I did an initial implementation of this and realized that the output sometimes differs between my version and the Perl version because of differences in the way floating point numbers are rounded when formatting to a string compared to calling round on an f64.

712.5f64.round() as usize results in 713, but print!("{:.0}", 712.5); prints 712.

The Perl version formats the samples like this:

my $samples = sprintf "%.0f", ($etime - $stime) * $factor;

But our version is using num_format, which doesn't support formatting floating point values. Currently I'm doing this before formatting:

let samples = ((frame.end_time - frame.start_time) as f64 * opt.factor).round() as usize;

Do we want to come up with a way to get the sample counts to match the Perl version in every case, or should we not worry about it?

[jonhoo]

I think we specifically need the result to not be a usize, since factor may be something like 0.01. @bcmyers any plans to add support for floating point numbers to num-format?

[jasonrhansen]

The Perl version formats the samples in the end without the fractional part. Are you saying you want to diverge from this behavior? If so, how many decimal places would we want to show?

[jonhoo]

Ohh, you're entirely right! I misread that part of the Perl code. I think what we want here is f64::floor or f64::trunc (not sure how they're different), both of which would exactly match the Perl version. Let's continue discussion in #65.

[bcmyers]

Yes - I had always planned to add floating point support to num-format, but it's a bit more complicated than integers. I'd like to read and (at least partially) understand some of the following kind of stuff before I get started (just a sample of various stuff on the topic that's out there):

• https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf
• https://github.com/miloyip/dtoa-benchmark
• https://github.com/dtolnay/dtoa
• Default float formatting is too narrow-minded rust-lang/rust#24556

But if inferno needs it, I'd be happy to prioritize the feature!

Doing a very naive implementation, by the way, would be super easy, but it would be just that, a very naive implementation. But if you wanted a temporary stop-gap feature added, I could do the naive version quickly while I work on implementing a faster algorithm for later release.

[jonhoo]

@bcmyers thanks, I appreciate that, but from the discussion above I think it's fine for us to just convert to an integer and then format, as that's what the Perl implementation is doing :)

[bcmyers]

Sounds good.