Shall quadratic complexity of join_all be documented?

[vi]

• futures::future::join_all on JoinHandle is too slow tokio-rs/tokio#2401
• https://users.rust-lang.org/t/hyper-tonic-client-performance/47253/2

[Nemo157]

Maybe even a

#[cfg(debug_assertions)]
if futures.len() > 1000 {
  warn!("join_all is only intended for running small dynamic lists of futures, use FuturesUnordered for large numbers");
}

(probably could even be a much lower limit, I don't know if anyone has ever tested what a good limit is).

[vi]

Does futures really use log?

[Nemo157]

Not currently, but the only other option I can think of would be debug_assert! which seems far too drastic to me.

[taiki-e]

(I think the fundamental solution is to change the name to include a word that describes its feature(=only efficient for relatively small lists), but that's a breaking change of course.)

[Darksonn]

Another option would be to have it use FuturesUnordered internally when the number of futures is large.

[EFanZh]

Does try_join_all and select_all suffer from the same issue?

[Darksonn]

Yes. For try_join_all it is exactly the same. For futures::future::select_all, it's a bit harder to hit, but it's still there. (Note that futures::stream::select_all is a different story.)

[ibraheemdev]

Is 30 a suitable limit? It could probably even be something lower, like 10, but it really depends on the cost of polling the specific future type.

[taiki-e]

#2412 is published in 0.3.17

[mox692]

I may be missing something, but is there a reason we are using FuturesOrdered instead of FuturesUnordered?

[Xuanwo]

I may be missing something, but is there a reason we are using FuturesOrdered instead of FuturesUnordered?

The order in which future results are returned is important.