[erlang-questions] Wanted additions to the maps module?

[Björn-Egil Dahlberg]

2016-05-10 1:59 GMT+02:00 Grzegorz Junka <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160510/a683fc6b/attachment.htm>