There is a feature to do just that:
@impl true
def init(state) do
{:ok, state, {:continue, :after_start}}
end
@impl true
def handle_continue(:after_start, state) do
# start living
end
lud
7
qhwa
PJUllrich
Author of Building Table Views with Phoenix LiveView
Thank you all very much for your input! You folks are awesome!
Unfortunately, I still can’t reproduce the speed gains by the asynchronous execution. Async takes 2x longer than sync (10.000 processes - 650ms vs 1200ms, 50.000 processes - 15s vs 28s).
Here’s my code: PeterAndCode/game_of_life/lib/game_of_life_web/live/page_live.ex at main · PJUllrich/PeterAndCode · GitHub
I checked that the Cell.ex doesn’t do too much work in its init/2 function and rewrote it using the handle_continue-pattern, but there were no notable performance gains. This isn’t surprising since the Cell wasn’t doing much in its init/2 anyway, but only sent a message back to the LiveView.
Any hints about how to decrease the time to spawn 50.000+ processes is still much appreciated, but I have the feeling that it simply takes this long 
PS: Does it maybe have something to do with my Elixir/Erlang setup? 
Maybe the BEAM is only using one out of the 6 cores I have instead of all 6?
PPS: The BEAM starts up with the following info:
Erlang/OTP 24 [erts-12.0.4] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit] [x86_64-apple-darwin20.6.0]
It appears to use all 6 cores and their multithreading ([smp:12:12]), but has only one async-thread? This seems to be the default
Could somebody who’s execution is faster in async verify that you only have 1 async-thread as well?
0
rvirding
Creator of Erlang
Just to be a bit picky here, starting a GenServer does more than just spawn a process. So the GenServer.start_link will spawn the process and then sit and wait until the new process does the necessary initialisation to become an OTP process and then calls the behaviour’s init callback. When that has completed the GenServer.start_link will return {:ok,pid}. This is a synchronous operation which is well defined in how a GenServer behaviour works. Can you get around it? NO, all you can do is try and make the init callback as fast as possible. Check the documentation for tips for doing that.
If you want to check how fast you can spawn processes just do a spawn instead, of course then you won’t get a GenServer. 
8
gregvaughn
PJUllrich
Author of Building Table Views with Phoenix LiveView
Uuuuuuh that’s so smart! And YES! That was the problem!
I removed sending a message from the init/1 of the cell back to the LiveView. I can now spawn 40.000 processes in only 300ms! Previously it took around 7 seconds. Amazing! Thanks so much!
The async version still takes 2x the time though, but I’ve given up on understanding why. If anybody wants to continue the investigation, this is my code.
Thanks again @gregvaughn and @rvirding and all the others for your very helpful input! 
3
PJUllrich
Author of Building Table Views with Phoenix LiveView
I wrote down my findings in a blog post
https://www.peterullrich.com/simulating-game-of-life-with-100000-erlang-processes
4
PJUllrich
Author of Building Table Views with Phoenix LiveView
Sebb
I was just wondering. I have something similar and tried to find a better solution than trial and error - but didn’t.
0