Slow after 100 clients? about automerge-classic HOT 2 CLOSED

Every client extends the vector clock width, so each new operation has to record the state of all the other actors that were visible when it was made. As you add more clients, this becomes ever more expensive.

We think this is not a fundamental limitation but rather an opportunity for optimization. If you are interested in using automerge then some detailed notes about your use case, benchmarks for where and how things get slow, or even better, a design or patch that mitigates the performance problems are all welcome contributions.

from automerge-classic.

Also, this caveat is less true now than when it was written. The internal change storage now uses minimised vector clocks that don't include all actor IDs, but only those actor IDs that have made changes. Thus, the cost of having a lot of actor IDs is now lower than it used to be, assuming that only a small number of actors are active at any one time. However, there are still some places that use full-width vector clocks (notably, Automerge.Connection for synchronising clients), so it's still a good idea to be a bit careful about how many actor IDs are generated.

from automerge-classic.