I think using ets will still introduce similar side effects.
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.
No doubt that ETS has much more functionality and is more sophisticated. But...
As the process dictionary update/lookup operations move only the references, not the whole data (see the accurate answer by Christian), it can be much faster, especially for big data structures. Once I refactored a part of code to keep the big and frequently accessed data structures in proc. dict instead of ETS and we had a 30% speedup in that part of the code.
In many cases the data is accessed only by a single process. In that case I don't see a big theoretical difference between the proc.dict and ETS. Both serve for keeping side effects in memory. Besides, you can access the proc.dict of another process like
process_info(whereis(net_kernel),dictionary).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With