Hello Yjs Community,
I’ve been exploring the performance optimizations in Yjs and came across an interesting observation when using the two different update handlers. Here’s the test I conducted:
doc.on('update', u => {
console.log('V1:', u.length, 'bytes');
});
doc.on('updateV2', u => {
console.log('V2:', u.length, 'bytes');
});
doc.transact(() => {
for (let i = 0; i < 100000; i++) {
doc.getMap().set('a', 0);
doc.getMap().set('b', 0);
}
}, doc.clientID);
// Log Output
V1: 1983505 bytes
V2: 62 bytes
As seen in the log, the optimization in version 2 (updateV2) is gigantic compared to version 1 (update). This led me to consider the necessity of using the YKeyValue class from the y-utility library, which is designed to handle efficient key-value storage by mitigating issues with Y.Map when keys are updated in an alternating order.
Here are some benchmark results comparing Y.Map and YKeyValue:
| Operations | Keys | YKeyValue Doc Size (bytes) | Y.Map Doc Size (bytes) | JSON Size (bytes) |
|---|---|---|---|---|
| 100k | 10 | 271 | 524,985 | 121 |
| 100k | 100 | 2,817 | 578,231 | 1,291 |
| 100k | 1,000 | 30,017 | 593,834 | 13,891 |
| 500k | 10 | 329 | 2,684,482 | 131 |
| 500k | 100 | 3,013 | 2,954,249 | 1,391 |
| 500k | 1,000 | 31,005 | 2,992,244 | 14,891 |
My Question:
With the significant optimizations introduced in updateV2, does this reduce or eliminate the need for using YKeyValue for managing key-value stores in scenarios where frequent and alternating updates occur? In other words, can updateV2 handle the optimizations that YKeyValue was initially designed to address, thereby simplifying the implementation by relying solely on Y.Map?
Thank you!