[erlang-questions] Wanted additions to the maps module?
Björn-Egil Dahlberg XB
bjorn-egil.xb.dahlberg@REDACTED
Tue May 10 09:36:29 CEST 2016
Another key issue I forgot to mention. It matters what payload you use and the size and structure of the keys. For the ETS measurement it matters a lot. You have to copy the entire payload for each get and insert.
Performance wise Maps usually beats ETS. Apples and Oranges however. ETS has other features so it's not a fair comparison.
// egil
Sent from my iPhone
10 maj 2016 kl. 03:10 skrev Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED<mailto:wallentin.dahlberg@REDACTED>>:
2016-05-10 1:59 GMT+02:00 Grzegorz Junka <list1@REDACTED<mailto:list1@REDACTED>>:
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:
https://gist.github.com/amiramix/d43c9a73a6fe6d651d7f
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.
Well, you are comparing apples and oranges. Process dictionary and ETS are something completely different from gb_trees, dict, maps or orddict.
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.
Yep, I take issue with it.
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.
It all depends on what you want to measure though, so look it over.
Another approach would be to use erts_debug:flat_size/1. With the functional data structures in this test you'll get:
- dict: 67568
- gb_trees: 78668
- map_match: 58543
- list: 78665
- orddict: 78665
// Björn-Egil
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160510/1af1dae7/attachment.htm>
More information about the erlang-questions
mailing list