[erlang-questions] Re: How to make the Erlang VM predictible when spawning processes?
Fri Jun 4 17:21:52 CEST 2010
Having pre-spawned processes doesn't mean you have to reuse them.
You could just spawn them ahead of time, say 1000 of them, let them
terminate as normal. Once you request a process to give it a task and you
notice that you've passed a threshold, say, < 500 free processes left, you
can spawn a process that forks 1000 more and adds them to the pool of
waiting ones. Example numbers of course but with a setup like this, it might
work good enough.
Or, alternatively, once a process has done it's job, instead of simply
terminating, spawn a new one and add it to the free pool. That way the
number of pre-spawned processes should be more constant and the performance
hit of spawning shouldn't matter that much as you are done with your (main)
On Fri, Jun 4, 2010 at 9:22 AM, Ovidiu Deac <> wrote:
> If I only have transient processes I can avoid the garbage collection
> by setting the initial heap to a value which is big enough for the
> process. If I reuse the processes I can't make this optimization.
> This is why I was thinking that reusing processes is not good.
> On Fri, Jun 4, 2010 at 12:31 PM, Jesper Louis Andersen
> <> wrote:
> > On Fri, Jun 4, 2010 at 10:43 AM, Ovidiu Deac <>
> >> I was hoping that the latency introduced by the OS would be lower and
> >> we would have enough time to satisfy the 10ms requirement. If you are
> >> right then I guess 10ms response time is not realistic on a standard
> >> system.
> > Shooting partially in the dark here. But what if you had a small set
> > of already spawned processes able to do the work when required? I
> > would guess you can eliminate some of the spawn-time with that
> > solution. It is not much different from minimizing the time spent
> > under a lock by preallocation.
> > --
> > J.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions