Hi all,
Is it a good idea to use the process dictionary as a small cache database?
Is there a limit to how many items a process dictionary can contain?
Just the available memory.
It depends, but usually not. For data you want to use within a given process you’re almost always better off just passing it along as an argument. If you want a “caching” data structure, pass along a map with keys / values as the cache. If you use the process dictionary the behaviour of your function will change a lot depending on what other functions were or weren’t called, and it makes your program harder to reason about.
5 Likes
It is a difficult choice to make!
The
globalmodule/server uses the process dictionary as a key-value cache for remote node configurations. Thefprofapplication makes a similar use of it for its internal state.
https://ferd.ca/on-the-use-of-the-process-dictionary-in-erlang.html
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.
https://stackoverflow.com/questions/1483550/in-erlang-what-are-the-benefits-of-using-ets-instead-of-process-dictionary-with/9819524
Thanks you so much!
FYI:
The main design objectives ETS had was to provide a way to store large amounts of data in Erlang with constant access time (functional data structures usually tend to flirt with logarithmic access time) and to have such storage look as if it were implemented as processes in order to keep their use simple and idiomatic.
Warning! Don’t use ETS as a cache prematurely! Log and analyze your application performance and identify which parts are bottlenecks, so you know whether you should cache, and what you should cache. This chapter is merely an example of how ETS can be used, once you’ve determined the need.
3 Likes
