4 ms·
>Sending large data structures to other processes always means serialization penalties, even if those processes run on the same CPU the trade off is that every
by knome 5y ago
>Sending large data structures to other processes always means serialization penalties, even if those processes run on the same CPU
the trade off is that every thread has its own gc arena that can be freely and quickly cleaned, and even better, often simply dropped entirely when the thread ends
there's never a stop the world moment, only the specific greenthread that's used up all its space.
OTP setup for managing processes in a standard way is also a big boon to developing in the language.
if you need to mangle some giant datastructure concurrently, sure, erlang is likely to not be what you need. but if you're just trying to toss out a cluster of interconnected nodes that can handle tons of concurrency and your interprocess messages are largely queries to threads dedicated to managing some resource or lump of data, it's a great setup.
- im_down_w_otp 5y agoThe original complaint also isn't true. Large binaries sent as messages actually end up reference counted and managed by BEAM that way. This is specifically to avoid expensive memory copies and fragmentation. I don't remember what the size threshold is off the top of my head anymore, but it's "large" by 1980's standards, not by today's. Something like 64 bytes.
- toast0 5y agoHeap binaries are limited to 64 bytes as you guessed, but to be pedantic, the limit isn't only for sending, anytime you make a binary larger than 64 bytes, it will be a RefC binary, which includes the at least 255 byte binaries that can get allocated for the append optimization. [1] This particular optimization can backfire if you're not careful. If you generate short binaries that trigger this optimization and then store them in ets, it references the existing binary which has a lot of extra space. If you hit that binary:copy/1 will return a perfectly sized binary you should store in ets instead. This same kind of thing can happen if you make a sub binary from some large binary (like a service response) and store it. [1] http://erlang.org/doc/efficiency_guide/binaryhandling.html#constructing-binaries http://erlang.org/doc/efficiency_guide/binaryhandling.html#c...