stevensonmt
It appears that the Elixir Map implementation is mostly an ergonomic wrapper for :maps in Erlang. In many graph/network exercises I’ve been faced with the need to convert a structure of List of Lists to something accessible by index. I have been mostly doing this by
list
|> Enum.map(fn row -> row |> Enum.with_index() |> Enum.map(fn {n, i} -> {i, n} end) |> Map.into() end)
|> Enum.with_index()
|> Enum.map(fn {v, k} -> {k, v} end)
|> Map.new()
So that I end up with %{0 => %{0 => n_0 ... n => n_n } ... } that I can access with graph[row][col].
Would Erlang arrays be a more efficient structure for repeated access? I’m assuming more than 32 elements, so the large map vs small map distinction is not the determining factor. In my mind Maps were lists of two-tuples but I’m not sure that’s right, at least for large maps. Arrays seem to be implemented as tuples of n-tuples. My instinct is that arrays would be more efficient at write functions but maps more efficient at read/access functions. Am I on the right track? Any tips on setting up a benchmark?
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
Not only library, but also the benchmarks:
https://github.com/Qqwy/elixir-arrays
benwilson512
You should also try
%{{0, 0} => value}that is accessedgraph[{row, col}]. I have a feeling this is faster since it’s one lookup not two.al2o3cr
One minor code-golf: anytime you see
Enum.map |> Map.new/1you can useMap.new/2instead.I doubt there’s a material performance difference (it’s still
:maps.from_list/1ultimately building the output) but it’s definitely less charactersstevensonmt
@hauleth Brilliant, thanks. Looking at the graphs in the benchmark section of the library’s readme I’m not sure I understand the conclusions in the corresponding text about the ErlangArray vs MapArray implementations. For instance:
To me the different implementations seem identical at sizes >8k according to the graph. In any case they seem to be close enough to equivalent for my purposes. I’m glad someone has already put this work in.
@benwilson512 Thanks for the tip. You are right of course about the efficiency, but the tradeoff would be
nlookups fornlength rows if I ever wanted to deal with things by row. It also is just easier for me to keep it visualized in my head.@al2o3cr That’s a good tip. Thanks.