Use futuresordered in join_all

[ibraheemdev]

Switch to FuturesOrdered in join_all when dealing with large amounts of futures. We will probably need benchmarks to determine what SMALL is.

Closes #2201

[ibraheemdev]

I think CI is failing because FuturesUnordered is feature gated under cfg_target_has_atomic?

[taiki-e]

I think CI is failing because FuturesUnordered is feature gated under cfg_target_has_atomic?

Yeah, I think you probably have to use #[cfg(not(futures_no_atomic_cas))] on JoinAllKind::Big. (In other words, if atomic CAS is not available, always use JoinAllKind::Small.)

[taiki-e]

I think CI is failing because FuturesUnordered is feature gated under cfg_target_has_atomic?

Yeah, I think you probably have to use #[cfg(not(futures_no_atomic_cas))] on JoinAllKind::Big. (In other words, if atomic CAS is not available, always use JoinAllKind::Small.)

Btw, at the time this PR was opened, it was cfg_target_has_atomic, but now it is futures_no_atomic_cas after #2400 has been merged.

[ibraheemdev]

 error[E0599]: no variant named `Big` found for enum `JoinAllKind<F>`
  --> futures-util/src/future/join_all.rs:45:9
   |
37 | / pin_project_lite::pin_project! {
38 | |     #[project = JoinAllKindProj]
39 | |     pub enum JoinAllKind<F>
40 | |     where
...  |
45 | |         Big  { #[pin] fut: Collect<FuturesOrdered<F>, Vec<F::Output>> },
   | |         ^^^ variant not found in `JoinAllKind<F>`
46 | |     }
47 | | }
   | |_- variant `Big` not found here

Is this a pin-project-lite problem?

[taiki-e]

Yeah, that is pin-project-lite's limitation: taiki-e/pin-project-lite#3 (comment)

[taiki-e]

LGTM. Thanks @ibraheemdev!

[stuhood]

Hey folks! Thanks for the optimization. Were any benchmarks performed for this? Also, would the same optimization apply to https://github.com/rust-lang/futures-rs/blob/dd019055ef5bf4309f15db934407e202caf52e14/futures-util/src/future/try_join_all.rs ? It seems to have the same shape.

[ibraheemdev]

Good point, try_join_all could use the same optimization. Note that this is not a complete fix, if you pass a large iterator without a size hint, the issue is still there. No, no benchmarks were performed, but the issue is quite apparent, although SMALL could probably be tweaked.