This is local, the OTP one is distributed. You shouldn’t use the OTP one to store local data, as looking up or storing information may require messages across nodes.
On my benchmarks, the use of partitions have only been justified for the pubsub/dispatch use cases. For the unique registry, I couldn’t find a case yet where increasing the number of partitions matter. However, my current machine has only 2 cores. Maybe a partitioned unique registry may matter on machines with 16+ cores.
:gproc is a great project, albeit I find its API confusing (YMMV). If you asked me about a registry in Elixir six months ago, the answer would likely be no. So what has changed?
- I confirmed with the OTP team they have no plans to tackle a local registry
- While working on a separate project wth @chrismccord, we realized we could generalize the PubSub implementation while keeping the scalability aspects of Phoenix.PubSub
- The generalization of PubSub made it useful for at least 2 other common cases: :via lookups and module/function dispatching. :via lookups is a frequently required feature. Plus I am using module/function dispatching to replace GenEvent in another app and we will explore it instead of GenEvent in Logger too.
Being faster than gproc is a perk, although the registry was designed to scale with multiple cores. Work in the registry is always done on the client, there is no centralized entity, and that’s another useful pattern to have in hand.
In other words, there isn’t a single reason. We found a generic solution that is performant and scalable and our reaction is that it can be very useful as part of the language.
