mattbaker
Consequences of using ordered:true in async_stream when piping to Enum?
So here’s something I’ve been puzzling over. We have the result of Task.Supervisor.async_stream_nolink(Sup, [], &foo/1) piping into Enum.flat_map. I think my specific question would pertain to any use of the async_stream family.
I understand if I pass ordered: true to async_stream_nolink the results will feed into Enum.flat_map in order, and if I pass ordered: false they will feed in in the order the spawned processes complete.
Behind the scenes, what is happening to these processes spawned by async_stream when ordered is true or false? My assumption was that, regardless of what I pass for the ordered option, all tasks will need to complete before Enum.flat_map begins doing work. So in either case, things will need to buffer.
Is that true? In this specific scenario, is there any difference in terms of computation, memory usage, or process lifetime when I pass ordered: true or false?
We previously were using ordered: false, but recently have a need for ordered: true, and we’re trying to figure out if there are any consequences related to computation speed or memory.
I’ve walked through the Elixir codebase and docs a fair amount trying to find an answer but didn’t manage to piece it together myself.
I also know this is kind of a hard question to express, so I can certainly try to clarify or rephrase ![]()
Most Liked
LostKobrakai
Yes. When Enum.flap_map asks for the value of the first stream item then :max_concurrency number of processes are started. With ordered: false the first value to return is supplied to Enum.flap_map. With ordered: true any value done earlier as the first would be buffered until all prev. ones were given to Enum.flap_map.
benwilson512
Yes, but keep in mind that max_concurrency is still the ruler here at the end of the day. If you set max_concurrency: 4 then maybe the first item is slow, and so it has to buffer 3 items until the first item finishes so it can emit it first, but it doesn’t have to buffer infinite items, just max_concurrency - 1 worst case.
mattbaker
Yes! That’s what I meant but I didn’t phrase it well, I think “4 items at a time” was poor wording on my part. More like… in a contrived example you could see an Enum function processing things and chronologically they might come in “bursts” of four, though it’s still consuming one item at a time. That seems to match what you’re describing as well.
Alright, I think I have the big picture in place.
Thank you both! This was insanely helpful.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









