Slow query from localdatastore

[FreudGit]

Using iPhone 5(on sim it was instant), query fromlocaldatastore take a bit more than 2 seconds to get approx 600 results. (very more that sqlite request)

The funny thing are that querying and get results from online a near faster!! :)

To reproduce:

• Get online data and pin it (queryDataFromParse)
  Close the app(or not)
• get all data from LocalDatastore (queryShareFromParse_UsingLocalDataStore)

-(void) queryShareFromParse_UsingLocalDataStore {
NSLog(@"--[%s:%d]",PRETTY_FUNCTION,LINE);
PFQuery *query = [PFQuery queryWithClassName:@"A_Sharing"];
query.limit = 1000;
[query fromLocalDatastore];
NSError *error;
NSArray *aContents=[query findObjects:&error];
if (!error) {
NSLog(@"--[%s:%@]",PRETTY_FUNCTION,@"->Results received");
}
}

-(void) queryDataFromParse {
NSLog(@"--[%s:%d]",PRETTY_FUNCTION,LINE);
PFQuery *query = [PFQuery queryWithClassName:@"A_Sharing"];
[query orderByDescending:@"updatedAt"];
query.limit = 10000;
[query findObjectsInBackgroundWithBlock:^(NSArray *aContents, NSError *error) {
//if (error) return;
if (aContents.count>0) {
[PFObject pinAll:aContents];
PFObject *pfObject=aContents[0];
}
}];
}

I can provide sample and ApplicationId to your private email.

[richardjrossiii]

LDS performance has been a known issue with the SDK for a while now. Its issues stem from multiple things, and are tightly tied to the object schema you have. We should probably create a master issue related to LDS performance, as theres a lot of things that need to/should be done there.

Unfortunately none of these improvements have any timeline right now, although it's high on my (personal) priority list.

[FreudGit]

Hi. (and thanks Richard)

The object schema are very simple. (< 20 column)

Any workaround?

Maybe i can provide you my sample project, easy to test\reproduce?

These 2 sec should be 300ms.

Creating a section for the LDS performance should be great. At least, we will have a way to see a more clear status.

[richardjrossiii]

By object schema, I was referring to objects which contain values of the following classes:

• NSArray
• NSDictionary
• PFACL
• PFGeoPoint

(The classes defined here)

If you have any values of those types your performance is going to be significantly worse for the foreseeable future.

[FreudGit]

Ok, thanks.
Do you think using [query includeKey:@"xx"]; to exclude some column with particular data type, can help?

[richardjrossiii]

No, that will not help. The current LDS architecture involves loading and reloading PFObjects from LDS multiple times, and includeKey: will not effect that.

[FreudGit]

Hi., sorry, i mean [query selectKeys:@[@"myColumnName"]];

I've just tried (keeping only one String type column), and, strangely, I don't get any performance gain. (still 2.2. sec.)

Maybe it can be a good start for you. :)

-(void) queryShareFromParse_UsingLocalDataStore {
NSLog(@"--[%s:%d]",PRETTY_FUNCTION,LINE);
PFQuery *query = [PFQuery queryWithClassName:@"A_Sharing"];
[query selectKeys:@[@"myColumnName"]];
query.limit = 1000;
[query fromLocalDatastore];
NSError *error;
NSArray *aContents=[query findObjects:&error];
if (!error) {
NSLog(@"--[%s:%@]",PRETTY_FUNCTION,@"->Results received");
}

}

[FreudGit]

One last comment.

Even use

query.limit = 1;

Doesn't help(still 2.2 sec)

Want me to start 2 requests for all this? ;)

LDM optimisation

• query.limit = 1000; = should help\impact result speed
• [query selectKeys:@[@"myColumnName"]]; = should help\impact result speed

[richardjrossiii]

No changes to your query will change the performance of it, the performance issues you see are related to the object schema. LDS always loads the entire object (it in fact loads every object for a specified pin) from SQLite, regardless of any query options you pass. -selectKeys: only effects server-side results.

I am well aware of where these performance issues lie, and while I appreciate your eagerness to help, I do not believe this problem can be solved without breaking changes at this time. The entire LDS architecture will need to be mostly re-done in order for things to get significantly better at this time.

Thanks for reporting this, and know that it will eventually get better.

[FreudGit]

Ok, thanks (and sorry).
F.

[richardjrossiii]

New master issue for performance of LDS: #32.

[nlutsenko]

@FreudGit One of the things that would help a lot would be to use small pins that encapsulate lists of data or queries that you use the most on any specific screen.
The smaller is the pin - the faster it is to query from that pin.

You can treat small pins the same as limit on queries in terms of potential speed improvements, and while limiting queries doesn't actually make it faster - using small pins does.

[FreudGit]

Thanks. I'll try it.

A;so note that even [query whereKey:@"myColumnName" lessThan:@2]; doesn't help :(

Your PIN "trick" = Not super useful if I need to get different results. (I have different sort, I can add a pinname for each, but it will not be cool to manage.)

You are doing a great job in parse and localdatastore. BUT a query with 2.3 sec to load... make this feature not super usefull.

Any timeline to take a look at this? (and\or do you think someone will be assigned to this in the next months?)

Continue your good work... open source, better communication with user, etc. You are in the good way!

[FreudGit]

For fun, and base on your comment:

I've tried to [PFObject pinAll:aContents withName:@"hello"];
And, after, to get all the results using pinname.

No luck, still 2.3 sec.

Argghh, even get results from your server are faster\lightning fast. :)

[paatz04]

same problem here ... has anybody done a custom sqlite implementation ?
If I'm going to implement something my self, what is the best way to reassemble the parse object after fetching it from the DB ? Thanks!