Ignore same values when using copyToRealm

[cmelchior]

This PR changes the implementation of copyToRealm to use Object Stores Object::create method.
This allows us to ignore fields with the same value. Currently this generates a lot of extra set instructions when syncing Realms which has a negative performance impact on the server.

A side-effect of this is also that using this method fine-grained notifications will not report any changes for this field. However this is only true if using copyToRealm or copyToRealmOrUpdate

Implementation is done by adding a new OsObjectBuilder class that will build up a list of data on the C++ side before creating the whole thing. From the user API side, we have a new ImportFlag enum.

Enums are being used instead of booleans or int flags since that mirros the API used by RealmObjectSchema for specifying field properties. It also has the upside of being more typesafe (plus I strongly suspect more flags in the future).

// New enum
enum ImportFlag {
  DO_NOT_SET_SAME_VALUES
}

// Usage
realm.copyToRealm(object, ImportFlag.DO_NOT_SET_SAME_VALUES)`
realm.copyToRealmOrUpdate(object, ImportFlag.DO_NOT_SET_SAME_VALUES)`

For the first iteration only copyToRealm/copyToRealmOrUpdate will use this method. We should consider adding the same flags to other methods like and createOrUpdateFromJSon*. insertOrUpdate is designed to be super performant, so it is unclear if we can support ImportFlags in this method without a lot of extra effort.

Performance

Performance in the new implementation is pretty much on par with the current performance. When diffing is enabled performance decrease about 20% which is unavoidable as all properties needs to be compared with what is on disk.

5.8.0

5.7.0

Diffed vs. non-diffed performance in 5.8

Relevant files to review

• java_object_accessor.hpp contains the majority of the C++ code
• io_realm_internal_objectstore_OsObjectBuilder.cpp contains the JNI boundary
• OsObjectBuilder contains most of the Java code, but isn't really very interesting.
• See all the proxy classes for the change to the output from the annotation processor

TODO

• Cleanup Changelog
• Cleanup Javadoc
• Javadoc in OsObjectBuilder
• Finish unit tests of OsObjectBuilder
• Cleanup OsObjectBuilder
• Modify annotation processor to use OsObjectBuilder
• Update annotation processor unit tests.
• Performance test
• Add unit test for notifications triggering correctly
• Any input to name of flag? Other suggestions: DO_NOT_WRITE_SAME_VALUES, IGNORE_SAME_VALUES? Others.. The current choice is somewhat arbitrary
• Send flags to C++
• Hook up into Object Store (using a WIP branch)
• Fix JavaContext::print() crashing on CI
• Remove use of util::Any or figure another way to get performance back to normal.

[cmelchior]

Is this safe?

[cmelchior]

Ready for review @nhachicha @kneth

[nhachicha]

Nice job ❤️ I think we need to update insertOrUpdate even though it's faster, it's still not optimised to generate fewer SET instructions for Sync

[cmelchior]

All comments addressed @nhachicha.

While it is true that ideally this should be added to all ways of importing data, it isn't clear it is worth the effort currently. It is, no matter what, outside the scope of this PR. I have created #6263 that tracks adding it to the rest of our API's

[cmelchior]

Ups. Some other comments where hiding. All should be fixed now

[nhachicha]

👏when CI is happy