Slow after 100 clients?

[adelriosantiago]

Could you please expand on this:

Caveats: Small number of collaborators: Automerge is designed for small-group collaborations. While there is no hard limit on the number of devices that can update a document, performance will degrade if you go beyond, say, 100 devices or so.

What causes this? Some kind of change history? I'm looking to switch to CRDT but this limitation could be a bit problematic.

[pvh]

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.

[ept]

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.