<div dir="ltr"><div>Perhaps an easy solution would be to document, unofficially of course so it is not doucmented, exactly how erts_debug:flat_size/1 works.<br><br></div>Robert<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 September 2014 11:27, Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
    <div>On 09/26/2014 06:46 AM, Sverker
      Eriksson wrote:<br>
    </div>
    <blockquote type="cite">On
      09/26/2014 04:19 AM, Michael Truog wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        I have been attempting to compare the output of
        erts_debug:flat_size/1 to the memory info at
        <a href="http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923" target="_blank">http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923</a>
        and the results show that each term's size is off-by-one (at
        least for pids local/remote, refs local/remote, floats,
        integers, bignums, binaries and atoms).  I know the function is
        experimental, but this is a bug, right?  The problem affects
        top-level terms and nested terms, so it is likely to understate
        the memory with large terms.  I wanted to make sure the memory
        info (in the efficiency guide) was accurate (it seems like it
        is).  I was testing with R16B03 on 64bits.
        <br>
        <br>
        For example:
        <br>
        1> erts_debug:flat_size(576460752303423488).
        <br>
        2
        <br>
        2> erts_debug:flat_size(576460752303423487).
        <br>
        0
        <br>
        3> erts_debug:flat_size(undefined).
        <br>
        0
        <br>
        4> erts_debug:flat_size([]).
        <br>
        0
        <br>
        5> erts_debug:flat_size([undefined]).
        <br>
        2
        <br>
        % 1 word for each element in the list * 2 elements including []
        <br>
        6> erts_debug:flat_size(erlang:make_ref()).
        <br>
        3
        <br>
        7> erts_debug:flat_size(erlang:self()).
        <br>
        0
        <br>
        8> erts_debug:flat_size(1.0).
        <br>
        2
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      erts_debug:flat_size/1 is undocumented and can therefor not be
      wrong by definition :-)
      <br>
      <br>
      But no, there is no bug, erts_debug:flat_size/1 works as intended
      in the current implementation. It returns the number of words on
      the _heap_ occupied (*) by the term. Excluded are thus off-heap
      data such as binaries larger than 64 bytes AND the top term word,
      which is kept in a register or on the stack.
      <br>
      <br>
      (*) erts_debug:flat_size does not take sharing of sub-terms into
      account while erts_debug:size/1 do.
      <br>
      <br>
      1> A = "Hello".
      <br>
      "Hello"
      <br>
      2> erts_debug:flat_size(A).
      <br>
      10
      <br>
      3> erts_debug:flat_size({A,A}).
      <br>
      23
      <br>
      4> erts_debug:size({A,A}).
      <br>
      13
      <br>
    </blockquote>
    <br></div></div>
    Thank you for the information.  However, based on this the
    Efficiency Guide memory information should be slightly wrong (at
    <a href="http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923" target="_blank">http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923</a>),
    since the information should be<br>
    * List: 1 word + <code>2 word per element</code> + the size of each
    element<br>
    * Tuple: 2 words + <code>1 word per element</code> + the size of
    each element<br>
    <br>
    and not what it currently is:<br>
    * List: 1 word + <code>1 word per element</code> + the size of each
    element<br>
    * Tuple: 2 words + the size of each element<br>
    <br>
    That is at least what I have found when using erts_debug:flat_size/1
    in the repo <a href="https://github.com/okeuday/erlang_term" target="_blank">https://github.com/okeuday/erlang_term</a> when looking at
    the total size of an Erlang term.  Do you agree?<br>
    <br>
    Thanks,<br>
    Michael<br>
    <blockquote type="cite">
      <br>
      <br>
      /Sverker, Erlang/OTP
      <br>
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div>