• map code clean #21
• narrow Item::{left/right} type from Node to Somr<Item> #24
• refactor map implementation #26
• Update consumes [u8] instead of Vec<u8> #35
• make Item::Content inner easier to share, especially for Value::Read (perf)
• standardize Value::read(Content) for type content reading (perf/correctness)
• try separate map/list into branches (mem reduce)

Currently we still use yrs as a baseline for binary compatible behavior, which increases testing complexity

I consider introducing a js runtime to provide the execution results of yjs as a reference benchmark during testing

It may be a convenient choice to directly use node to execute and output to stdio. Another option is to introduce quickjs or a similar streamlined js runtime, but this will increase compilation time and dependency complexity.

I will first investigate the feasibility of using nodejs to obtain execution results. This is the easiest way

### Tasks
- [x] https://github.com/toeverything/y-octo/pull/4
- [x] impl the function binding of node: #6
- [ ] test case for verify the data between yjs and y-octo-node #6

ybinary v1 is a binary format optimized for one-time network transmission.

It only supports overall reading and cannot know whether binary is damaged before the reading process goes wrong.

For specific analysis, please refer to this review:

toeverything/OctoBase#383 (comment)

We need to design a binary format that supports partial reading and self-verification to store crdt state permanently and robustly

In the previous iteration, we have implemented most of lib0 and crdt logics:

• toeverything/OctoBase#383
• toeverything/OctoBase#403

We need to verify the correctness and consistency of it with yjs in our new Node.js sync server.

I feel like this libraries readme could better explain how exactly it is different from the normal Y.js library.

For example, by comparing data or use-cases. It's quite foggy right now.

I just connected yocto to a community-created benchmark and found that the performance of the codec part was significantly lower than other crdt implementations: https://github.com/darkskygit/crdt-bench-native



After a simple inspection, it was found that the current implementation took a lot of time on memory allocation.

https://docs.codspeed.io/

In yjs, sub doc is loaded in the following way:

let doc = new Y.Doc()
console.log('init main doc');

doc.on('subdocs', ({ loaded }) => {
  loaded.forEach(subdoc => {
    console.log('init subdoc provider');
    new SomethingProvider(subdoc.guid, subdoc)
  })
})

let subDoc = doc.getMap("map").get("some_sub_doc")
subDoc.on('synced', () => {
  console.log('synced');
  // when doc synced by provider, we can get sub doc's data
})
console.log('loading');
subDoc.load()

// exec workflow:
// init main doc -> loading -> init subdoc provider -> synced

In y-octo, we have implemented the parsing of sub doc identifiers in ydoc, this means that to add subdoc support to y-octo, what we need to do is:

• provide an API to allow doc to know its own synchronization status
• provide an API, pass in a doc instance, and use external implementation to load the doc binary from anywhere and apply update
• maintain a thread-safe weak reference to a subdoc instance inside doc