LDS Performance Improvements

[grantland]

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 (Remove mutable container tracking #108)
• Make LDS query matching more efficient by not loading every object into memory for a specified pin.
• Make LDS use ParseObjectState and ParseUserState instead of ParseObject and ParseUser, to reduce the amount of locking required for every LDS operation.
• Improve LDS ParseRelation 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:
  • Collection and its subclasses
  • Map and its subclasses
  • ParseACL
  • ParseGeoPoint
• 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.

See parse-community/Parse-SDK-iOS-OSX#32

[Allsimon]

Is there any documentation concerning which version is the fastest ?
@FreudGit uploaded an interesting spreadsheet in parse-community/Parse-SDK-iOS-OSX#32 and I'm wondering if performance improvement are shared between iOS/Android

[swapnilgt]

@grantland
After our application is scaling a bit, we are hitting the performance ceiling on the LDS. I have started seeing some activity lately on the Parse-Android-SDK (almost after an year). Are there any plans to resolve the performance issues with LDS in android. Anyways, I have the following questions regarding the performance tips mentioned above:

• When you say "Keep your object schemas as small as possible - the faster it is to parse them from JSON, the better.", what is the scale you are talking about?
• When you say avoid using "Collection and its subclasses" and "Map and its subclasses", you mean not to use these in the extended custom ParseObjects at java layer?
• "Whenever possible, use smaller pins", do you recommend to have less number of entries in a particular class that I have pinned or do you recommend that I can have thousands of records pinned for a particular class but pin then sets of, let's say, 100 records?