In Erlang, what are the benefits of using ets instead of process dictionary within a process?

Question

I think using ets will still introduce similar side effects.

Answer 1

Benefits of ETS over process dictionary are:

• Other processes can access the ETS table directly
• ETS gives you searching / matching / iteration facilities, while the process dictionary is only a key-value store.
• You can save/load tables to files in one step
• If your owner process dies the table can be inherited by someone else, so the data is not lost.

Answer 2

ETS is not garbage collected since it is stored in a heap outside of erlang processes. This means that when you put something into ets it is copied into it, and when you take it out, you get a copy in your process. Making lots of ets lookups can then lead to excess consing in your process (but this is only relevant for very high througputs).

The process dictionary is garbage collected. It is stored in the process's own heap. So when you look things up in it you get a reference to the exact same value you put in it. The values stored in the process dictionary are not compacted.

Both approaches are non-pure, i.e. they have side-effects. Yes it is bad, and yes it is not why we have both alternatives.

Answer 3

ETS more or less behaves as if the table was in a separate process and requests are messages sent to that process. While it is not implemented with processes that the properties of ETS are modeled like that. It is in fact possible to implement ETS with processes.

This means that the side effect properties are consistent with the rest of Erlang.

The process dictionary is like nothing else in Erlang and adding it was a big mistake. There is no reason to use the process dictionary instead of one of the process local dictionaries like dict or gb_trees.