When benchmarking thousands of processes registering serially, it is twice slower than local atoms, albeit 33% faster than gproc. On concurrent cases, it distributes well across all cores, becoming only 15% slower than local atoms, and 3x faster than gproc on a machine with two cores (gproc seems to be serial with its default configurations so the difference will be even bigger on more cores).
Please give it a try and let us know what you think.
Ooo, so basically an Elixirfied :gproc it looks like? That is awesome if so! ^.^
EDIT: Indeed it does, a bit more simplified in the docs as I’m not seeing anything like :gprocs local and remote distinctions or pubsub helpers and such, but it looks like the pubsub helpers can be build on what is here, and the local and remote distinctions are probably not necessary if it is naturally distributed.
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.
Wonderful! The implementation seems very clean and understandable
Noob question: what would be the utility of having multiple partitions for the same Registry? Looking at the code I see that the registry uses only one by default. In which cases should I use more partitions than the default one?
I believe it would be great to have this become part of Elixir’s core or at least the ‘officially maintained packages’, as it is a very common use case.
What was the main reason behind starting this project? In the first post you mentioned that Registry is somewhat faster than gproc: Was this (make it faster) the main reason to start building this? Or are there features that you feel are missing from gproc and other existing alternatives that are important enough to start something new?
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.
This looks great. I had a quick go at replacing gproc in an app I’m working on. There’s one place where I use the await functionality of gproc to wait for a particular worker in a parallel supervisor hierarchy to start and register itself. Now that I look at the code I’m not sure if I need it but I was wondering if there were any plans for something similar?
Semi related question… I store the worker pid in a phoenix channel state. Would it be better to look this up in the registry each time I use it or grab it once and monitor in the channel?
Not right now but I believe it could be implemented using the partitioning semantics, so that seems possible.
Looking up every time is cheap and simpler, so maybe that? Unless you need to synchronize state between both processes. In this case, you need to associate them somehow by either monitoring or linking.
@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!).
I am not sure I am reading the spreadsheet well – but did anybody make a benchmark on the Macbook 2015? The 12" with a single USB Type-C 3.1 port? I have it and can run the benchmark anytime.
EDIT: When I run a benchmark, how do I contribute the results to the spreadsheet?
I have bumped the version to 0.2.0. This version removes whereis/2 in favor of lookup/2. The new lookup/2 function works on both unique and duplicate registries.
put_info/3 and update/3 have also been added.
That spreadsheet is about one single 40 cores machine. Feel free to copy it and add your own numbers.
