The Registry has been merged into Elixir master.

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?

1. I confirmed with the OTP team they have no plans to tackle a local registry
2. While working on a separate project wth @chrismccord, we realized we could generalize the PubSub implementation while keeping the scalability aspects of Phoenix.PubSub
3. 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.

Its API is quite simpler than gproc’s. There is no support for distribution as well, it is by definition local. One reason why we are hesitant on tackling any distributed registry as part of Elixir is because such is already part of the OTP team plans.

@voltone and others have benchmarked the registry. I have consolidated @voltone results here:

Summary: on a machine with 40 cores, a Registry with 40 partitions provides across the board better results on concurrent registration. Without partitioning, the Registry starts to scale poorly when the concurrency factor is somewhere between 8 and 20.

Surprisingly, gproc performs quite well, even in concurrent scenarios. <speculation>I am assuming serializing writes ensures there is no contention for concurrent threads, so less coordination and process switches.</speculation>.

Erlang’s built-in atom registration does not perform well in highly concurrent scenarios but that’s fine. It was not meant to support dynamic names registration anyway (and doing so would certainly be a bug in your app!).

Registry has been updated to v0.3.0 with:

1. Improved performance for 1 partition (most common case)
2. Allow a process to update its own value
3. Support for named listeners
4. Allow metadata to be stored along-side the registry

The last two features should make the registry more extensible. Listeners allows you to give a named process when the registry is started that will receive events whenever a process registers or unregisters a key. You could use those features to add Await support to the registry or even use the registry as a pool. We have added an example of using the registry as a sojourn pool to the examples directory. The pool is an example, do not use it in production:

https://github.com/elixir-lang/registry/blob/master/examples/sojourn.exs

The pool above measures the sojourn time, which is how long messages stay in each pooled process queue. That provides an idea of how fast processes are responding. Whenever there is a dispatch, we pick two random pooled processes and choose the one with the most recent reply and smaller sojourn time.

The pool itself works by starting a worker and a registry. The worker is a listener of the registry and a supervisor guarantees that both are restarted in case any of crashes. Whenever a new process is added to the registry, the worker is notified and starts sending sampling messages to that process which updates its own entry in case of crashes.

I hope it serves as inspiration for playing with the registry for other use cases.