<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/26/2014 11:27 AM, Michael Truog
      wrote:<br>
    </div>
    <blockquote cite="mid:5425B023.6080906@gmail.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 09/26/2014 06:46 AM, Sverker
        Eriksson wrote:<br>
      </div>
      <blockquote cite="mid:54256E44.1080305@erix.ericsson.se"
        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
            moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923">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>
      Thank you for the information.  However, based on this the
      Efficiency Guide memory information should be slightly wrong (at <a
        moz-do-not-send="true" class="moz-txt-link-freetext"
        href="http://www.erlang.org/doc/efficiency_guide/advanced.html#id68923">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 moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="https://github.com/okeuday/erlang_term">https://github.com/okeuday/erlang_term</a>
      when looking at the total size of an Erlang term.  Do you agree?<br>
    </blockquote>
    After looking at this more I have realized the documentation of the
    memory information is correct as would be expected.  Sorry for the
    noise about this.  Some comment that talks about
    erts_debug:flat_size/1 (and erts_debug:size/1) providing the process
    heap size only, with an additional 1 word excluded for the register
    or stack storage of the top-level term would help make things
    clearer.  This may be straight-forward for some since it makes
    logical sense, but I didn't know about these internal details and I
    wanted to be sure I was looking at the size correctly.<br>
    <br>
    Thanks,<br>
    Michael<br>
    <br>
    <br>
    <blockquote cite="mid:5425B023.6080906@gmail.com" type="cite"> <br>
      Thanks,<br>
      Michael<br>
      <blockquote cite="mid:54256E44.1080305@erix.ericsson.se"
        type="cite"> <br>
        <br>
        /Sverker, Erlang/OTP <br>
        <br>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>