Why limit the number of steps sent to the server?

[smoores-dev]

In getCommit, there's a hard cap on the number of steps included in a commit: https://github.com/stepwisehq/prosemirror-collab-commit/blob/main/src/collab-commit.ts#L122. It's set to 20 — it seems as if it was maybe meant to be configurable at one point, but it isn't actually exposed directly to users.

Is there a reason for this cap?

[ProTip]

@smoores-dev I believe this was an attempt to limit the "chunkiness" of any given document update while under heavy load. It should probably be exposed through sendableCommit.

[smoores-dev]

It would be great to expose it, maybe with the ability to disable it as well! Would you be open to a PR that does that?

[hausdorff]

@ProTip I would love to hear more about the effect of the chunkiness you've seen in practice! I wrote some very bad and preliminary benchmarks over the weekend, happy to share and trade notes if helpful. Roughly what I think we've found is:

• For networking configurations where individual requests take a "very long time" (e.g., POSTing to an HTTPS server on a connection that takes 1-2 seconds to fully initialize the connection before data is transmitted), I found that "moderate sized" chunks seem to often take 2x-3x longer to get accepted than if you send them all at once.
• On any modern, "fast" connection, either chunking or not chunking is "roughly the same performance," (in that I believe users are unlikely to notice a difference). So all good there. (I believe you probably expect this is true.)
• I am not 100% sure what your design constraints are for the network and step history size but together given those things my guess is that for most connections it's probably better to just transmit all the steps at once by default.
• The one asterisk I will note here is that I did not send super, super huge step requests—I am guessing that if you are trying to transmit a prohibitive amount of data the on a terrible connection there are circumstances where you'll have a lot of trouble getting all the requests to the server. I think more likely than having a lot of outstanding edits, you would encounter this when pasting enormous documents. We don't have this problem so I just kind of left it at that.

If this reflects the assumptions you're making about network and step size then I think we're happy to produce a PR to make all-steps the configurable default. If it does not, I think we're also happy to keep this default and simply make it configurable.

Let us know what you think, and thanks for your work on the library!

[ProTip]

TL;DR This has been addressed in #9

The use case for this setting is documents with a high number of active editors each with variable network conditions and high edit velocity.

Example:

• A 50+ person meeting where members are all actively editing the document adding updates, ideas, and anecdotes
• 60fps update target affording at most 16.66ms of JavaScript execution per tick

The commit represents a unit of work that must be applied atomically. Limiting the number of steps in each commit is a tunable to facilitate more fine grain interleaving of edits on the backend, and lower latency application of the broadcast commits on the client side.

Applying a single step, full document paste uses far less resources(CPU time and memory) than processing the 60k individual steps that originally constructed the document. Limiting commit size helps limit "apply" time of any one commit and thus helps mitigate typing latency(keystroke to paint). Smaller commits provide a "smoother" editor experience compared to "chunky" updates when integrating remote commits.

In my client this is just a sanity cap; commit size grows naturally with confirmation latency.

[smoores-dev]

Thank you for explaining this, @ProTip! This absolutely makes sense, and is something that I honestly hadn't thought about at all as a constraint.