Flatbuffers marshalling performance

[vaind]

The way we currently marshal and unmarshal flatbuffers into objects isn't optimal. We should get rid of the intermediary propVals map<string, dynamic>. Ideally creating objects (or flatbuffers in the other direction) directly in the generated code.

[greenrobot]

Yes, this should use code generation for both ways.

Once this is done and reviewed, please give me the final review.

[Buggaboo]

Can we borrow anything from google's flatc?

[vaind]

I think we're already calling the right methods from flatbuffers. Just not being 100 % efficient for the whole roundtrip.

[greenrobot]

We should have a minimal CRUD perf app before doing that?

[Buggaboo]

What is the bottleneck here precisely? Runtime property selection using the Map? Can we use the offsets to get/put the data from a stream of bytes? I have a feeling we might need ByteData. N vs. NlogN?

[greenrobot]

Look at how Go does it, e.g. the generated code here:

• Flatten(): object (struct) to FlatBuffers
• Load(): FlatBuffers to object

Go does the FlatBuffers handling directly, while Java FlatBuffers handling is to slow and defers that to JNI. I hope compiled Dart is closer to Go performance, so it's at least worth a try.

[Buggaboo]

It could be even faster with caching probably e.g. maintain last_write and last_read timestamps in atomic transactions.

[greenrobot]

ObjectBox already benefits from OS cached memory mapping (see FAQ for some details). We did not bother about object-level caches so far, as ObjectBox gets like 1 million objects per second from the DB on regular notebooks.

[Buggaboo]

I'm looking into benchmark harness.

How does one stress test the library? N number of writes to a random (sub)set of fields, and reads? Then print the CPU processor type, number of cores, and memory?

[vaind]

This (future) change in vm/ffi will allow us to avoid copying the data from FlatBuffers builder to OBX_bytes_wrapper (or other c-backed memory) dart-lang/sdk#44589 👀