<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Why would decoding a term create *any* garbage in typical cases?</div><div class="gmail_default" style="font-family:monospace,monospace">One source of garbage in my Smalltalk library is that floats are</div><div class="gmail_default" style="font-family:monospace,monospace">represented as an integer power of two scale modifying an integer</div><div class="gmail_default" style="font-family:monospace,monospace">(which might be a bignum), so the second integer (if large) is</div><div class="gmail_default" style="font-family:monospace,monospace">garbage.  But Erlang doesn't do that.  It represents a float as</div><div class="gmail_default" style="font-family:monospace,monospace">8 binary bytes.  The reason is that my Smalltalk had to deal with</div><div class="gmail_default" style="font-family:monospace,monospace">double extended, which could be 64, 80, 96, or 128 bits, so the</div><div class="gmail_default" style="font-family:monospace,monospace">external representation had to deal with it, but Erlang supports</div><div class="gmail_default" style="font-family:monospace,monospace">64-bit IEEE doubles only.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Erlang's external format follows the ASN Type-Length-Value</div><div class="gmail_default" style="font-family:monospace,monospace">principle (more or less), so that when binary_to_term/1 reads</div><div class="gmail_default" style="font-family:monospace,monospace">something, it knows exactly what to allocate and how big.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">What am I missing here?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 8 Jun 2021 at 00:47, Lukas Larsson <<a href="mailto:garazdawi@gmail.com">garazdawi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jun 7, 2021 at 2:38 PM Thomas Depierre <<a href="mailto:depierre.thomas@gmail.com" target="_blank">depierre.thomas@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div dir="ltr"><div>Yes there is a pretty simple answer :) Parsing is far harder than serialization ! for parsing, you have to read a bit of the binary stream, find what type it is, then translate the data to a data type, which means allocating memory. On top of that you need to validate that it is not a mangled binary stream. And you need to do it piecemeal, with a lot of information about current steps. This is far more complex than translating a particular memory setting that you know the size of into a binary stream.<br></div></div></div></blockquote><div><br></div><div>Another thing that comes to mind is that the GC may be interfering with the results as binary_to_term would create more garbage than term_to_binary.</div><div><br></div><div>Lukas</div></div></div>
</blockquote></div>