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

[Grzegorz Junka]

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.

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.

Greg


On 09/05/2016 16:29, Robert Virding wrote:
> OK, I am the one who asked for first/next so this is my use case.
>
> As Lukas mentioned I need this to implement Lua tables in Erlang using 
> maps.
>
> I need to be able to iterate over a map one key/value pair at a time. 
> For me the order is completely irrelevant as along as if I do a 
> sequence of first-next-next-... using the previous key in the next 
> next I am guaranteed to *uniquely* get *all* the keys in the map. If I 
> modify the map and try to continue from where I was then all bets are 
> of and there are no guarantees any more that I will get all keys or 
> that they will be unique.
>
> Lua has exactly this interface to its tables so I need to be able to 
> do it as well. Not having it is not an option. So while having maps or 
> folds over a map is great there is no way these can be used to 
> implement what I need efficiently. That's it.
>
> Now I use a private 2-3 trees implementation of dict with the added 
> functions and it works well. But using maps would seem logical and 
> more efficient.
>
> That's about it.
>
> Robert
>
>
> On 9 May 2016 at 16:54, Fred Hebert <mononcqc@REDACTED 
> <mailto:mononcqc@REDACTED>> wrote:
>
>     On 05/09, zxq9 wrote:
>
>         On Monday 09 May 2016 15:22:17 Lukas Larsson wrote:
>
>             On Mon, May 9, 2016 at 2:54 PM, zxq9 <zxq9@REDACTED
>             <mailto:zxq9@REDACTED>> wrote:
>
>             >
>             > That's my whole point. Why the desire for a next/1 and
>             previous/1
>             > instead of a list-style operation over the map as a
>             whole, since
>             > outside of an abstract sense of "doing something with
>             each element"
>             > there is nothing interesting that can possibly be gained
>             from
>             > introducing an implicit concept of order?
>             >
>
>
>         Sure, internally I imagine there are a million super slick
>         ways to use this,
>         and I lack the imagination to see what they may be.
>
>
>     - partial iteration to look for an element
>     - partial iteration to only modify a subrange of the whole map;
>     for  example, re-hashing a window of N components. If your map has
>     10  million items and you want to re-hash 25 of them, then going
>     over the  whole map every time is going to eat you up on the
>     computation (this  one is more useful with a total stable order
>     defined)
>     - implementing your own map/fold/filter combination as a single pass
>      without needing to iterate and convert the whole map at once
>     - ability to do lookahead/look-behind in an iteration to
>     arbitrary  levels without implementing your own ad-hoc zipper or
>     buffering all of  the content you have seen
>
>     Those are a few I have in mind can be doable that way -- I've
>     mostly seen them at work or wanted them for ETS tables, but I'm
>     sure someone could twist a map into having the same requirements.
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> 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/20160509/5e1f637d/attachment.htm>