<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-05-10 1:59 GMT+02:00 Grzegorz Junka <span dir="ltr"><<a href="mailto:list1@gjunka.com" target="_blank">list1@gjunka.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>I only wanted to mention that maps is not the only key-value data
      structure available in Erlang and may not the best one to
      implement such an iterator. I once did a benchmark of available
      key-value data stores measuring not only the speed, but also the
      amount of consumed memory:</p>
    <p><a href="https://gist.github.com/amiramix/d43c9a73a6fe6d651d7f" target="_blank">https://gist.github.com/amiramix/d43c9a73a6fe6d651d7f</a></p>
    <p>Maps are quite performant but process dictionary is still quicker
      and maps are the worst when it comes to consumed memory, taking
      twice as much as dict or process dictionary and over 5 times as
      much memory as ets.</p></div></blockquote><div>Well, you are comparing apples and oranges. Process dictionary and ETS are something completely different from gb_trees, dict, maps or orddict.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p>BTW if you have a look and find any issues please let me know and
      I will be happy to correct and rerun. The test simply initializes
      the data structure with InitSize amount of Key-Value elements, and
      then starts measuring the time and memory needed to write/read
      Accesses amount of Key-Value/Key elements with randomly generated
      Keys.<br></p></div></blockquote><div>Yep, I take issue with it.</div><div><br></div><div>I think you should look over how you measure memory. It seems very arbitrary. What are you measuring? The size of the process after it all? The gc can shrink or grow the heap during execution, trying to find a suitable size. Also look at the number of gc:s during the execution, this will indicate how garbage you are generating. Normally benchmarks ends with an explicit garbage_collect before looking at the size. This gives a more fair indication of memory consumption.</div><div>It all depends on what you want to measure though, so look it over. </div><div><br></div><div>Another approach would be to use erts_debug:flat_size/1. With the functional data structures in this test you'll get:</div><div><br></div><div>- dict: 67568</div><div>- gb_trees: 78668</div><div>- map_match: 58543</div><div>- list: 78665</div><div>- orddict: 78665</div><div><br></div><div>// Björn-Egil</div></div></div></div>