[Realm branch] Improvements

[designmanio]

[Realm branch] Improvements

[JulianKingman]

I'm going to close this. Although realm is somewhat attractive b/c of improved performance, I think v2 improves it enough that this is no longer necessary; it's also unclear just how much we can improve performance just by using realm, I think the bottleneck may be elsewhere. Plus, doing away with an extra react-native link means this can be used in expo.

[JulianKingman]

If you look closer, the schema just defines collections and documents, allowing for an artitrary number of collections and an arbitrary document shape, making it more compatible with the "meteor way". I feel like defining a shema for every collection is very "stiff", especially because schema are declared differently in realm than Mongo. Maybe I'll test the stringify stuff, to see if it's really a performance bottleneck. My theory is/was that because I store each doc separately (compared to asyncstorage), keyed by id, it would perform pretty well.

The for loop shouldn't be a problem.

[balibou]

Right ...
Mmm I don't really know then ...
I will try to make the thing working without going throught the package and compare to the code of connectMeteorRedux.js ...

[JulianKingman]

Here's a jsperf on JSON.stringify: https://jsperf.com/json-stringify-versions/3
93,759 operations per second should be fast enough :)
Also, looking at the forEach again, it's just looping through the collections, of which there likely won't be many, so not a lot lost there.

One thing we could try is throttling saves, so they're added in bulk on a timer, instead of on every DDP addition/update/removal (mainly the initial load is the problem, since it fires an 'added' event for every downloaded document.

On the 'restore' side, I still don't know why it's so slow. Is it actual disk write speeds, or... something else? This is the main problem.

[balibou]

Ahah yes, but there is the parsing process to take into account too :)
[WITHOUT REALM]
I've tried with 10 and 100 objects in Asyncstorage and the performances are totally different ! (stringify and parse)

[WITH REALM]
I have rendered 10 and 100 objects using same schema I used in simple schema on meteor and there are absolutely no problem ! (absolutely no use of stringify)

[JulianKingman]

Any code you can share?

[JulianKingman]

Also, I don't really notice a performance issue until over 1000 records

[balibou]

It was just shitty tests but I will do it :)

[JulianKingman]

So there's this related issue: realm/realm-js#491
Basically, with the chrome debugger enabled, realm performs much much much slower. Testing this on the example (for which I added a setting that creates 10,000 records), performance is pretty snappy. Give it a shot and let me know how it works.
Hopefully they fix it soon, as never enabling debugger would be rather unfortunate.

[balibou]

Yes, but even if I remove chrome debugger / or run it on my iphone, it's pretty laggy ...

[JulianKingman]

How many records are you dealing with, and how big are the objects? I'm seeing next to 0 performance hit for the 10,000 moderate/large objects.

[balibou]

Sorry for the delay ...
just 100 objects, but with nested objects and arrays inside.
I will provide you an example as soon as I can

[JulianKingman]

Huh, 100 should be no problem. Is it a repo you can share? It seems like maybe something else is going on

[balibou]

Yeah but with the error "Document.fields must be of type: string" it won't actually work on my repo ...

[JulianKingman]

Give v2.0 a try. It has a different API, so be aware of that.

[balibou]

Cool ! Thanks will have a try this week end :)