No-op Configuration

[XAMPPRocky]

When using flamegraph profiling rayon pollutes the call stack making it very hard to find my code in the graph, and I have to manually replace all instances of par_. It'd be nice if I could instead enable a feature flag in rayon so that I don't have to change every code instance and just have to change Cargo.toml that simply made all parallel iterator calls sequential. I've included two graphs below with and without rayon calls to show the disparity between the two.

With rayon

Without rayon

[nikomatsakis]

Making this a feature makes me a bit nervous — if you accidentally committed it, or published with it, it would propagate to all your dependencies etc...

We could make a cfg setting that you have to set up with RUSTFLAGS easily enough though.

[cuviper]

Is it good enough for you to just use RUST_NUM_THREADS=1 in your environment? You'll still see some rayon in your callstack this way, but it should be greatly reduced.

AIUI flamegraph does a lot of post-processing in scripts. I wonder if you could just filter unwanted rayon symbols from your stacks that way? Then you'll still be representing the parallel workload otherwise, which could be helpful.

[XAMPPRocky]

@nikomatsakis That concern is completely valid. I was just using feature as an example. Any solution that is a single switch to flip is equally satisfactory.

@cuviper I've attached below what it looks like with RUST_NUM_THREADS=1 while it is shallower, it is still far from readable in my opinion.

[mashedcode]

We could make a cfg setting that you have to set up with RUSTFLAGS easily enough though.

That sounds like a great solution!

[AnEnigmaticBug]

We could make a cfg setting that you have to set up with RUSTFLAGS easily enough though.

Hi. Is there any update on this? I see that the issue has been open for 4 years now. Just wanted to check if it will be picked up some time later this year. I also have the same use case (cleaning up perf output) and would love to have this!

If no one is taking a shot, I can try making a pull request (disclaimer: I haven't looked at rayon internals till now). Any pointers would be really helpful!

[cuviper]

Also see the discussion in #861, but I'm not aware of anyone actually working on it yet.

[RReverser]

I believe this was closed by #1019 / #861?

[cuviper]

Not entirely -- I think OP wanted this on platforms that do support threads well, but all the work-stealing makes it hard to decipher what's going on in tools that look at backtraces, like flamegraph.

I have had luck using cargo flamegraph --skip-after=SYMBOL when there a decent entry point into the parallel work to filter on, or even just using the rayon_core::join::... functions in some cases. Then it can run fully parallel and still get a decently understandable flamegraph image.

[RReverser]

Not entirely -- I think OP wanted this on platforms that do support threads well

Ah so the functionality is there, but the --cfg opt-in is still missing.

[cuviper]

You could also set threads=1 and use_current_thread (#1063).