No way to influence par_iter's decision when to fall back to sequential about rayon HOT 3 CLOSED

The intention was to able to be supply a weight, yes, and perhaps some methods to experimentally determine a good weight on sample workloads.

from rayon.

In response to this comment by @mneumann from #9:

This is sort of roughly what I had in mind, but it'd probably be a stage in the algorithm. Something like foo.into_par_iter().map().weight(22), which would indicate that the map operation takes "22x" the default time. This is trivial to implement, but you'd have to just kind of guess what the right number is (well, experiment). I am also rather concerned about the portability of these constants, both across machines/workloads and across releases of rayon.

One way to address that would be to have (and encourage the use of) an "autotune" option, where you provide a pipeline and a sample, and we vary the weights to find the one that seems to be running best. But that itself will be sensitive to whatever else the machine happens to be doing at the time which you tune, and it assumes you have some convenient time to do that tuning and data to tune with.

Overall, I'd rather find something more automatic -- and just optimizing join and the overall dispatch is perhaps the best answer I know of there -- but allowing one to manually specify weights might be a good fallback to have on the table.

from rayon.

See https://github.com/nikomatsakis/rayon/pull/12, which adds a weight combinator

from rayon.