Compute profiling time range from samples and markers

[nordzilla]

Overview

This PR adds profilingStartTime and profilingEndTime fields to the profile metadata, computed from all sample timestamps and marker start/end times across all threads.

Tests

I've updated all of the existing tests to check these values, but it doesn't have full coverage of the edge cases I've encountered, where marker times may be before/after sample times, or the converse, on multiple threads, etc.

I did manually verify that it fixes the issues I was seeing in #710 related to the profiling time range.

Example Before: https://share.firefox.dev/4oSRnGW

Notice that much of the right-most Fib(14) is truncated.

Example After: https://share.firefox.dev/4p5vUux

Notice that every Fibonacci call is wholly present.
The profile ends exactly at the end of the markers.

However, I'm not entirely sure if the current behavior is correct for every scenario.

For example, I'm not sure if the following start and end time of 10.0, which is the computed result for one of the current test cases, makes sense:

"startTime": 1636162232627.0,
"profilingStartTime": 10.0,
"profilingEndTime": 10.0,
"symbolicated": false,
"symbolicated": false,
"pausedRanges": [],
"pausedRanges": [],
"version": 24,
"version": 24,

I didn't add any additional test cases because I'm still very much a novice when it comes to the internals of the profiles. I bet an LLM could generate more test cases pretty well, given the context, but I wouldn't be able to accurately review whether it represents a realistic profile.

I'm not sure how extensive you want the test coverage, since these cases are pretty long, but I'm happy to try to add more cases if desired.

Additional Thoughts

I considered utilizing rayon for the compute_profiling_time_range() function, because it seems like a natural use case, and probably would drastically reduce the time to process large profiles. However, I didn't want to introduce a new dependency to this crate without asking.

Related Work

This PR was implemented as an alternative to firefox-devtools/profiler#5682.

[mstange]

Oh, I actually had a different change in mind: I think Profile should have set_profiling_start/end_time methods, and then samply can just set the right timestamps that way, and nothing has to be computed in an extra pass.

[nordzilla]

Thanks for the feedback! I should have time to look into it tomorrow morning.

---

EDIT:

Didn't have as much time this morning as I thought.

I'll get to this as soon as I can.

[mstange]

Thanks!

Here are some more specifics on how I think we should get the timestamps:

• samply record:
  • when launching a process, the timestamp we use for the launched process's start time should also be the profiling start time
  • when attaching to a process, the timestamp at which we're asked to attach should be the profiling start time
  • when profiling is stopped with ctrl+c, the time of the ctrl+c should be the profiling end time
  • when profiling stops because a process exits, the end time of the process should be the profiling end time
• samply import:
  • could leave as-is for now; if we need to infer the profiling time from the sample timestamps in the source file, we might as well keep doing that in the front-end as before

[nordzilla]

Update

I've been looking into this a bit.

I'm onboarding onto a lot more samply-internal context than, for example, emitting marker files in #710, or doing a min/max through the processed data (as was done in my first implementation attempt for this PR).

Even when I get this PR up, it will probably be macOS and Linux only. I don't have a Windows dev machine to look into and test those internals.