3 ms·

Erlang's Internal Data Representation (2016)

• davidw 10y ago
  That string as linked list thing can get ugly real fast: http://erlang.org/pipermail/erlang-questions/2014-September/081032.html http://erlang.org/pipermail/erlang-questions/2014-September/... 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.
• dom0 10y ago
  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.
  • deleted 10y ago
    [deleted]
• coldcode 10y ago
  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.