LDS Performance Improvements

[richardjrossiii]

This is a master issue for all things related to local datastore performance improvements.

• Make LDS stop checkpointing and making copies of objects for mutable containers (Removed 'mutable containers' functionality. #102)
• Make LDS query matching more efficient by not loading every object into memory for a specified pin.
• Make LDS use PFObjectState and PFUserState instead of PFObject and PFUser, to reduce the amount of locking required for every LDS operation.
• Improve LDS PFRelation tracking.
• Update LDS database schema to allow for query matching in the database layer itself.

For anyone reaching this issue as a result of currently bad LDS performance here's our current recommendations:

• Keep your object schemas as small as possible - the faster it is to parse them from JSON, the better.
• Relations are currently inefficient. If you can avoid them, do so.
• Minimize usage of any values of the following classes:
  • NSArray
  • NSDictionary
  • PFACL
  • PFGeoPoint
• Whenever possible, use smaller pins. Because LDS loads all objects in a single pin before evaluating a query, the smaller the pin is, the better.

[rawrmaan]

+1, LDS performance needs lots of work. I'm glad you're finally publicly acknowledging this. See my angry bug report from April 2015: https://developers.facebook.com/bugs/1575754175998187

[FreudGit]

+1: 2.3 sec to get one row on a table of 800 objects... Ouch.

[RickDT]

👍

[FreudGit]

Hi

Sorry to came back. Do you think one of these point can be associate to a milestone?

Maybe not clean, but a PFQuery with a whereKey pointing to a String can be filtered direct from the DB (json), without unwrap.

Just with this, Query time will be 99% smaller.

Just my 2 cents

[nlutsenko]

Hey @FreudGit, absolutely!
I've just attached a PR to this that implements the first bullet point in that list.
From our testing - it should improve performance significantly.

But you are right - we should attach more to milestones. Making it happen...

[FreudGit]

WOW, thanks for the fast reply.

PR? This was a bit to technical for me. But i'm happy if we can target and see better performance in the next release\weeks. 👍

[nlutsenko]

PR is a shorthand for Pull Request

Since removing mutable containers functionality can break few flows for people, we are sitting on it for a little bit longer than next release. I think we are going to ship it with 1.8.4

[FreudGit]

Thanks again @nlutsenko.
Wish 1.8.4 will come soon or that you will be ok to move to 1.8.3 milestone. Let me know if\when there is a way to try.

(completely off-topic)= how do you manage the multiple version(android, etc). Do you sync revision with other team(Android, .net, etc? Just curious!

[nlutsenko]

@FreudGit, 1.8.4 is coming very very soon after 1.8.4. A small tip is to look at the release schedule of 3 previous releases, it might get you an idea of how we try to release at the current moment.

So far we don't sync versions between Android/.NET/iOS(OSX), since we have separate dependencies.
If we are releasing a new feature that is cross-platform, say new Sessions APIs that we released at F8 - we do the release at the same time. Most of the time though - we have separate release schedules.