<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 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 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 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 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>
<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>
</body>
</html>