>Even if it by default preserves input order, when I explicitly called >stream.unordered(), could mapConcurrent() respect that and in return achieve >higher throughput with support for race?
The Gatherer doesn't know whether the Stream is unordered or ordered. The operation should be semantically equivalent anyway. Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: Jige Yu <yuj...@gmail.com> Sent: Monday, 2 June 2025 16:29 To: Viktor Klang <viktor.kl...@oracle.com>; core-libs-dev@openjdk.org <core-libs-dev@openjdk.org> Subject: [External] : Re: Should mapConcurrent() respect time order instead of input order? Sorry. Forgot to copy to the mailing list. On Mon, Jun 2, 2025 at 7:27 AM Jige Yu <yuj...@gmail.com<mailto:yuj...@gmail.com>> wrote: Thanks Viktor! I was thinking from my own experience that I wouldn't have automatically assumed that a concurrent fanout library would by default preserve input order. And I think wanting high throughput with real-life utilities like race would be more commonly useful. But I could be wrong. Regardless, mapConcurrent() can do both, no? Even if it by default preserves input order, when I explicitly called stream.unordered(), could mapConcurrent() respect that and in return achieve higher throughput with support for race? On Mon, Jun 2, 2025 at 2:33 AM Viktor Klang <viktor.kl...@oracle.com<mailto:viktor.kl...@oracle.com>> wrote: Hi! In a similar vein to the built-in Collectors, the built-in Gatherers provide solutions to common stream-related problems, but also, they also serve as "inspiration" for developers for what is possible to implement using Gatherers. If someone, for performance reasons, and with a use-case which does not require encounter-order, want to take advantage of that combination of circumstances, it is definitely possible to implement your own Gatherer which has that behavior. Cheers, √ Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.org<mailto:core-libs-dev-r...@openjdk.org>> on behalf of Jige Yu <yuj...@gmail.com<mailto:yuj...@gmail.com>> Sent: Sunday, 1 June 2025 21:08 To: core-libs-dev@openjdk.org<mailto:core-libs-dev@openjdk.org> <core-libs-dev@openjdk.org<mailto:core-libs-dev@openjdk.org>> Subject: Should mapConcurrent() respect time order instead of input order? It seems like for most people, input order isn't that important for concurrent work, and concurrent results being in non-deterministic order is often expected. If mapConcurrent() just respect output encounter order: It'll be able to achieve higher throughput if an early task is slow, For example, with concurrency=2, and if the first task takes 10 minutes to run, mapConcurrent() would only be able to process 2 tasks within the first 10 minutes; whereas with encounter order, the first task being slow doesn't block the 3rd - 100th elements from being processed and output. mapConcurrent() can be used to implement useful concurrent semantics, for example to support race semantics. Imagine if I need to send request to 10 candidate backends and take whichever that succeeds first, I'd be able to do: backends.stream() .gather(mapConcurrent( backend -> { try { return backend.fetchOrder(); } catch (RpcException e) { return null; // failed to fetch but not fatal } }) .filter(Objects::notNull) .findFirst(); // first success then cancel the rest Cheers,
