Performance issue when attaching doc

[hunkim98]

Description:

Hello, this is the creator of Toonie, a collaborative blueprint reviewing service created using yorkie-js-sdk. I have discovered that documents which have had many concurrent operations takes a lot of time to load initially. Some of the examples where you can check out the performance issues are

1. https://toonie.yorkie.dev/hello
2. https://toonie.yorkie.dev/nXIQ0KX

If you go into one the links addressed above, you can see that it takes some time to load the initial document. In my case, the /hello document took about 10 seconds to load!

Despite the document's simple data only consisted of serveral shape objects(lines, rect), it takes a considerably long time for initial load.

Why:

I have tried to analyze the problem through examining the performance tab in the browser. It seems that applySnapshot and deepcopy are the main culprits for the slow initial load.

Through testing multiple times in the local environment, it seems that it is not the amount of data that causes a slow initial load - No matter how many lines I draw in the locally-served toonie, the initial load does not take much time. Presumably, it is the amount of multiple concurrent operations that happen to cause such behavior.

The RHTPQMap is one presumable cause to this slow initial load since its use of a heap structure causes multiple shifting when there are concurrent operations.

Any discussions regarding this issue is welcome!🐤

[hunkim98]

Trying to find the problem of the slow loading, I hosted toonie at localhost and made the apis connect to the real yorkie api. And then when I tried to enter hello doc, the loading time was very short compared to the toonie.yorkie.dev (While toonie.yorkie.dev took about 7 seconds, on localhost it took only 1 second to load) It seems that the github page might be lagging somehow.

[hunkim98]

I have tried to compare the performance difference in the locally served toonie and the github page published toonie. I have discovered memory usage difference in them.

Github page published toonie performance

Locally served toonie performance

Analysis

As you can see in the above screenshots, the JS Heap memory consumption is different.

While locally served toonie ends up using 208 mb in the end, Github published toonie ends up using 635mb in the end.

Thus it seems that the lagging of toonie when published has more to do with the publish configuration rather than yorkie-js-sdk itself. I will update this thread while finding methods to optimize the github published toonie.

P.S

What is interesting is that 'deepcopy' in the published toonie takes way much time than locally served 'toonie'. Whiile 'bytesToObject' part seems to be a bit similar, there is a huge performance lagging when 'deepcopy' is called. Further investigation is needed to analyze the deepcopy problem.

[hunkim98]

After multiple trials, I think I have found a slight hint on the issue regarding the performance difference in the github published toonie and the locally served toonie. If toonie is run locally with the command 'yarn start', the performance issue of attaching document does not seem to be much different with the test case. However, when toonie is run locally with the static files built with 'yarn build', the performance issue greatly differs. This may be due to the compilation of typescript into javascript. It seems that the typescript based yorkie-js-sdk runs laggingly when compiled into javascript!