3 ms·
The 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
by im_down_w_otp 5y ago
The 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...