You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to be able to record the relationship between a "parent" thread and the tasks it spawns. Consider this:
use rayon::prelude::*;fndo_many_jobs(jobs:&[Jobs]) -> Vec<Output>{
puffin::profile_scope!("do_many_jobs")!;
jobs.par_iter().map(|job| {
puffin::profile_scope!("do_job");do_job(job);}).collect()}
This will show up as one thread with do_many_jobs, and then maybe four worker threads doing do_job. In the flamegrpah however, there is no relationship behind them. It would be great if each do_job scope had an arrow pointing to it from the do_many_jobs scope, showing their connection.
We could maybe accomplish this with something like
In the recording stream, these thread relationships would be rare, but would require some additional dynamic data. For instance, one extra control-byte which, if some bit is set in it, would be followed by a thread id.
We could use another bit in the same control-byte to indicate if there is any dynamic string, saving us a byte again in common cases.
The thread-id could be the u64 returned by std::thread::current().id().as_u64.
The text was updated successfully, but these errors were encountered:
I'd like to be able to record the relationship between a "parent" thread and the tasks it spawns. Consider this:
This will show up as one thread with
do_many_jobs
, and then maybe four worker threads doingdo_job
. In the flamegrpah however, there is no relationship behind them. It would be great if eachdo_job
scope had an arrow pointing to it from thedo_many_jobs
scope, showing their connection.We could maybe accomplish this with something like
In the recording stream, these thread relationships would be rare, but would require some additional dynamic data. For instance, one extra control-byte which, if some bit is set in it, would be followed by a thread id.
We could use another bit in the same control-byte to indicate if there is any dynamic string, saving us a byte again in common cases.
The thread-id could be the
u64
returned bystd::thread::current().id().as_u64
.The text was updated successfully, but these errors were encountered: