
Erlang's Internal Data Representation (2016) - weatherlight
https://edfine.io/blog/2016/06/28/erlang-data-representation/
======
dom0
Not so much interesting, but it rather looks grossly inefficient and a
complete antipattern in terms of data layout, unless Erlang has a very, very
capable allocator, that is able to correctly colocate all these linked
structures. Still, the bizarre overhead multiplies bandwidth requirements, and
pointer chasing multiplies memory access latency penalties.

------
davidw
That string as linked list thing can get ugly real fast:

[http://erlang.org/pipermail/erlang-
questions/2014-September/...](http://erlang.org/pipermail/erlang-
questions/2014-September/081032.html)

It was going from a binary like <<"foobar">> to a linked list string to print
out as part of the crash dump, so something like ['<', '<', 'f' ... etc which
absolutely blew up the memory, considering that the original binary was pretty
big.

------
coldcode
The tagged pointer/value trick (using the fact that allocations are aligned to
boundaries thus allowing for 2-3 bits of information you can use to tell which
is which) is a trick we used in my first MacOS app 30 years ago, though we
used bits at other end since you couldn't allocate the full address space on
those old Macs.

