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

[Grzegorz Junka]

>>>>      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.
>> What's the point of comparing gb_tress to gb_trees or maps to maps?
> Please misunderstand correctly.  Nobody is talking about comparing gb_trees
> to gb_trees.  What Björn-Egil said was that it is fair to compare any
> within the group (gb_trees, dict, maps, orddict) with each other since all
> are functional heap based data structures.  But it is not fair to compare
> any one in the group with neither the process dictionary nor with ETS.
>
> It is also hard to compare the process dictionary with ETS since the
> process dictionary stores on the process heap while ETS stores in other
> allocated memory.
>

If I need to store many key-value pairs I don't care which group the 
structure belongs to. I measure and it pick one that is most suitable 
for the job at hand considering all the limitations. Why should I limit 
the test to comparing only some data structures with some others?

In my test I am adding the memory consumed by the process and in ETS: 
process_size(E) + ets:info(Tid, memory) * erlang:system_info(wordsize).
It's hard but one need to start somewhere. It's not enough to say, it's 
hard, don't do it.

I am not saying that maps are implemented badly or that they are bad 
data structures. Only that they are not the only data structure that 
should be considered because everything comes with some limitations and 
trade-offs.

Grzegorz