Target performance for use in peerpad

[fritzy]

Since we want to use peer-crdt for peerpad, we need to create a performance test and determine a performance target.

• [x] 1,000 dag operation test with several branches and simulated network latency
  • several branches
  • network latency
  • use the register type and collide occasionally on set
• [ ] determine how many operations per second a typical peerpad session creates
  • 3 people typing at once
  • y.js + richtext type
  • Can peer-crdt keep up with a similar workload?
• [ ] develop textarea demo with peer-crdt
• [ ] develop richtext type for for peer-crdt

At this point, we can start implementing more optimizations if needed (faster dag merging, rollups to remove the need to fetch serially, etc).

[legastero]

For the DAG operations test, I had three peers in the network, where each peer was chosen randomly to apply one of N operations to a lww-register CRDT. This was a stress test, where all of the operations were performed rapidly, to see how long it would then take for the peers to converge.

When N was 500, it took the three peers 17 minutes to converge.

When N was 1000, the test ran for over 5 hours and then crashed from lack of RAM.

Profiling showed a performance bottleneck in the _isChildOf() log method, and an improved version of the method has been patched in https://github.com/ipfs-shipyard/peer-crdt/pull/8

Using the patched version, 500 changes took ~30 seconds before convergence, and 1000 changes took 70-80 seconds.

This is remarkably faster than before, but likely needs more optimization since this was using the virtual network used by the current tests and not including real-world network latency costs.