Performance of term_to_binary vs Bbinary_to_term

Lukas Larsson lukas@REDACTED
Tue Jun 8 16:21:34 CEST 2021


On Tue, Jun 8, 2021 at 2:57 PM Richard O'Keefe <raoknz@REDACTED> wrote:

> Why would decoding a term create *any* garbage in typical cases?
> One source of garbage in my Smalltalk library is that floats are
> represented as an integer power of two scale modifying an integer
> (which might be a bignum), so the second integer (if large) is
> garbage.  But Erlang doesn't do that.  It represents a float as
> 8 binary bytes.  The reason is that my Smalltalk had to deal with
> double extended, which could be 64, 80, 96, or 128 bits, so the
> external representation had to deal with it, but Erlang supports
> 64-bit IEEE doubles only.
> Erlang's external format follows the ASN Type-Length-Value
> principle (more or less), so that when binary_to_term/1 reads
> something, it knows exactly what to allocate and how big.
> What am I missing here?

The garbage I was referring to is the term itself. The term "garbage" may
not have been the best choice to describe that data.

In the initial question the benchmark was done on `{a,<<1,2,3>>, b,
[1,2,3], c, {1,2,3}, d, #{a=>1, b=>2, c=>3}}`, which would create 35 words
heap data when decoded.

However, when encoded it is represented by:
which is only 10 words of heapdata.

So each loop in the decode benchmark would generate 3.5 times as much
garbage for the garbage collector to deal with.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the erlang-questions mailing list