Is anyone else seeing massive increases in memory consumption while the prosemirror-collab plugin is active? We’re seeing significant usage for all users before collab, but we’ve just noticed that collab, particularly in many-user (4+ simultaneous editors) scenarios, the memory usage climbs through the roof. Even in a solo session I can top 1GB of memory in about 30 seconds.
It appears, from profiling in Chrome, that much of the extra memory consumption comes from the unconfirmed array. Turning off the rest of our plugins doesn’t actually do much to the behaviour, so I’m assuming it’s specific to collab.
Anyone having similar issues? Any thoughts on how to fix if so?
It is most likely the way you are using collab rather than the plugin itself.
How many unconfirmed steps are there in the array when you’re seeing the memory blowup? Where are they coming from and why aren’t they being confirmed?
I’m still characterizing the issue. I’ve seen as many as 37000, but that case appears to be isolated and to have been triggered by an invalid TransformStep early in the changelog which prevented remote clients from accepting further steps. Still, given the number of changes made during that session, 37000 was a surprisingly large number of steps.
I couldn’t say for sure why they’re not being confirmed, aside from the observation that there’s a fair bit of processing being done on the document in general in our editor, so when you’re typing quickly it can lose ground, and as the number of users working together rises the problem gets worse quickly.
Sorry for the lack of detail in the above, but I’ll post back when I have a better understanding of the behaviour I’m seeing. I’ve been on this all week, and I’ve seen everything from hard crashes in Chrome DevTools to a complete lack of issues at times. As I said, still trying to isolate exactly what the triggers are.
Futher analysis pointed to two issues:
We had a timeout that would sometimes do a delayed call to sendableSteps(), which appears to have been sometimes producing broken steps. I theorize that there’s a timeout somewhere in the PM code (Maybe the keystroke finalizer) that is overlapping and we’re getting some funky half-transformed states during our timeout. That’s pure hypothesis at the moment, however.
Firebase - we’ve updated our SDK version and restructured some of the surrounding code, so it’s not completely clear what caused this to start, but we were no longer receiving locally-created steps in receiveTransaction(), which was exploding the size of the unconfirmed list in some cases.
New states are created synchronously, as a new value, and then swapped in atomically, so that seems unlikely.