Is ETS definitely faster than storing and retrieving something from an agent? I’d been wondering about that but hadn’t seen any stats.
brightball
sasajuric
Author of Elixir In Action
Oh, in that case, Agent works perfectly fine here, sorry for wrongly accusing you 
I agree. Many people here said they don’t use agents all that often. And yet, in the official mix&otp guide, agents are the second lesson. I’m not sure they deserve so much spotlight, since it seems they are not used all that often in practice.
0
sasajuric
Author of Elixir In Action
In terms of speed ETS should always be faster, because it doesn’t go through the scheduler, and it also doesn’t put any pressure on the garbage collector. In terms of memory overhead, it’s ~ twice as much than process, so you want to be a bit careful not to create too many tables. The default limit is 1400 ETS tables (can be increased via command line).
Given its speed and the fact that it can support concurrent reads/writes, for a simple shared k-v structure used by multiple processes, I don’t even bother with agents/GenServer, and opt immediately for ETS tables.
On the flip side, in terms of atomic operations support, ETS is much more limited than standard processes. You can do some basic things such as atomically set some value, or increment a counter. So there are many cases where ETS table will not suffice, and in such cases GenServer (or derivatives such as Agent or :gen_statem) are your only option.
0
Qqwy
TypeCheck Core Team
Well, I would like to say that, at least in my personal opinion, grasping how Agents work and how to create them has a lot lower learning curve than grasping how the GenServer and related behaviours work and should be used. Of course, this might also be considered a bad thing if it leads to newcomers over-using Agents because they understand those.
As for using ETS over an Agent-argument: Do not forget forget that you should first make it correct, then readable, and only finally fast. If using an Agent is fast enough for whatever purpose it has in your application, the added complexity from using an ETS-based system might not be advantageous.
1
OvermindDL1
Yes.
Just flat-out yes.
Sometimes faster and sometimes slower depending on the options used to set up the ETS table, but regardless, ‘Yes’.
Except in very very specific situations that you are likely to never run in to, and even then only barely…
I’d still use ETS.
Overall though:
If I’m wanting to store/set data to be accessed by different processes, I’d use ETS.
If I’m wanting to store/set data to be accessed by different processes transactionally, I’d use Mnesia.
If I’m wanting to store/set data in a single process, I’d pass a value (map/tuple/record/whatever) through it.
If I’m wanting to bind some ‘actions’ to operating on data, I’d use GenServer straight.
I cannot really see any reason that I would ever use an Agent at all, there are better/faster methods in all cases that are more functional, both in syntax/code and functionality.
5
sasajuric
Author of Elixir In Action
That’s the big problem in my impression. Another problem is that IMO Agents don’t help much for learning GenServer. So while I agree that it’s easier to grasp Agents, I’m not sure that the gain is worth it.
Especially since basic GenServer (init, call, and cast) is not all that complicated (though admittedly still more than Agent).
I agree with this as long as there is some notable difference in complexity between correct and fast. For a k-v, here’s how it looks with Agents:
{:ok, pid} = Agent.start_link(fn -> %{} end)
Agent.update(pid, &Map.put(&1, :foo, :bar))
Agent.get(pid, &Map.get(&1, :foo))
and this is how it looks with ETS:
ets = :ets.new(:table_name, [])
:ets.insert(ets, {:foo, :bar})
:ets.lookup(ets, :foo)
In terms of code complexity these are mostly similar. In term of scalability, ETS will be much better than single proc in handling larger number of items, as well as larger number of clients. So in this situation, the choice is pretty clear to me
Otherwise, I mostly agree with what @OvermindDL1 wrote above.
3
mjadczak
I guess I feel/felt like for something which exists in memory for maybe a few minutes, making an ETS or Mnesia table feels really “heavyweight”, especially since with current scale it’s unlikely to make any measurable difference whether a process is used or ETS/Mnesia directly.
Maybe my inner sense of how “heavy” using those is needs to be recalibrated however. Maybe I incorrectly assume they’re this heavy extra thing because they are rarely mentioned in any educational material around Elixir. Up until now I would have only thought to reach for them when storing data for a longer time—e.g. where I would use Redis in another stack—and not to just store a small, transient amount of data.
0
OvermindDL1
Not at all, ETS is blazing fast, it technically works ‘outside’ the actor system so most communication with it is faster than anything else you could set up short of keeping it on the local actor’s stack. Plus the ETS table is killed when the process it is linked to dies as well.
That is because Elixir is… odd in some of its teaching. ^.^
In my opinion it really should have made ETS more front-and-center, like it is in Erlang, the EVM/BEAM is practically designed around ETS and making it fast.
0
alamba78
I read the same thing you mentioned from here:
It’s apparently how José Valim described the choice between using Tasks, Agents, and GenServer.
0
gon782
This is largely the reason no one seems to be using Mnesia, as well. It’s odd, because it’s such a great resource to have and use out of the box. People won’t use it even when what they have is generally perfect for it. I think it stems from records being something Elixir programmers generally know nothing about and all they know is “they’re bad” even though they’ve never had to work with them and so they don’t even know what’s bad about them (the syntax, that’s all). This, coupled with that no one in the core team seems to ever mention Mnesia, means that it’s something people don’t even consider.
When I started working with an erlang codebase I’d only worked with Elixir before and so I faced this personally. I was totally unprepared for how great Mnesia is and how easy it is to work with, because the Elixir community does an extremely bad job in highlighting what a great out of the box feature it is to have.
2