11–13 of 13 posts
Uhh, I've seen this too. Part of the reason we are migrating some code from Erlang to C.
It could be argued that this is a poor reason to switch from Erlang to C -- this is a problem with how binaries are handled in user code, not something intrinsic to Erlang VM.
Earlier quoted context omitted.
It could be argued that this is a poor reason to switch from Erlang to C -- this is a problem with how binaries are handled in user code, not something intrinsic to Erlang VM.
Eh, every factor involved is implementation detail. The threshold at which binaries are heap-alloc'ed, gc behavior, etc. I really fail to see how this is user error.
That isn't what the parent comment said.
I think two things are interesting here. 1: "when does Erlang GC a process' heap?" and 2: "where does Erlang keep a process' data?". 1: Erlang GCs a process' heap whenever that process' heap gets full, or when you call erlang:garbage_collect() explicitly. 2: Erlang stores most data associated with a process on the process heap, there's one such heap per erlang process. Binaries are a special case. If they're large (>…
Might this be considered a symptom of an architecture problem? I'm far from an Erlang expert but my understanding is that processes generally should be short lived, except for supervisors, which should only supervise. Instead of having a single long-lived process handling a lot of large binaries would a better design be to have separate processes handling each binary?