解析本地数据存储性能

我正在使用解析作为云存储，并结合本地数据存储进行一般访问。我发现查询本地数据存储需要比我预期的要长得多。使用数据填充表格或更新图形视图时，这一点尤为明显。 Coredata中的等效函数几乎是瞬时的，结果非常好。虽然我不指望coredata的性能，但它比我预期的离线访问要慢得多，我想知道我是否做错了什么？解析本地数据存储性能

下面是一个例子查询：

PFQuery *query = [PFQuery queryWithClassName:LOCATION_OBJECT]; 
[query fromLocalDatastore]; 
[query whereKey:MESSAGE_TO_FIELD equalTo:user.username]; 
[query orderByDescending:CREATED_FIELD]; 
NSLog(@"Query started"); 
NSArray* res = [query findObjects]; 
NSLog(@"Query finished, found %lu objects", (unsigned long)[res count]);

在2015年iPad的迷你执行排序定时是我看到如下：

2015-06-16 18:56:38.883 app[1744:1668474] Query started 
2015-06-16 18:56:38.885 app[1744:1668474] Warning: A long-running operation is being executed on the main thread. 
Break on warnBlockingOperationOnMainThread() to debug. 
2015-06-16 18:56:39.177 app[1744:1668474] Query finished, found 17 objects

我也明白，分析是提供远远超过只是一个数据库，但这个查询需要0.292秒，这似乎是一个年龄。对于我的应用程序，我经常在用户浏览屏幕时使用这种操作。随着coredata的结果非常好，解析滞后非常明显。值得一提的是，在模拟器上的结果是相似的。当你做这种事情时警告解析问题并不令人鼓舞，但无论如何，我的问题有两个：

1）我是否错过了Parse中的任何性能调整/设置？ 2）有其他使用Parse的人是否找到类似的表现或有任何建议？

此时，看起来我需要在应用程序中使用coredata并编写自己的例程来将数据推送到Parse的云，这比我所期望的要多得多。

谢谢你的时间。

更新30Jun15

感谢您的意见，按照这些意见，这里是从做解析它要你做的方式例如性能。与以前一样，与coredata相比，表现仍然很差。示例代码：

PFQuery *query = [PFQuery queryWithClassName:LOCATION_OBJECT]; 
[query fromLocalDatastore]; 
[query whereKey:MESSAGE_TO_FIELD equalTo:user.username]; 
[query orderByDescending:CREATED_FIELD]; 
NSLog(@"Query started ... "); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    NSLog(@"Query finished ... "); 
    if(!error) 
     NSLog(@"Found %lu message records in local datastore", (unsigned long)[objects count]); 
    else 
     NSLog(@"Parse error pulling messages from datastore: %@ %@", error, [error userInfo]); 
}];

性能在同一ipad公司：

2015-06-30 10:32:09.633 MvBii[205:5172] Query started ... 
2015-06-30 10:32:09.948 MvBii[205:5172] Query finished ... 
2015-06-30 10:32:09.948 MvBii[205:5172] Found 100 message records in local datastore

查询需要0.315秒。现在，和以前一样，我并不是说这本身就不好，可能对于很多应用程序来说这很不错，但它比coredata差几个数量级，而且对我的应用程序来说太慢了。当用户在屏幕上浏览图形时，由于此查询而绘制图形，并且我无法使用解析来快速更新屏幕，以响应用户输入。使用coredata的结果是非常好的。

我的主要问题是这个查询时间是否符合其他人的经验？我想知道我的应用程序或数据集是否有什么特殊之处？数据集不大（< 200项），解析对象只是字符串和整数。我仍然真的想为它提供的所有其他设施使用Parse。也许这只是我的期望已经关闭，但对于基本查询来说似乎很长时间。

来源

2015-06-26 pyrrhoofcam

它不是一个解析结束问题，它是一个开发结束的问题。该警告明确指出应该改变什么（主线程上长时间运行的任务），换句话说，对于表或任何接口更改所做的更新应在主线程中完成，所有其他异步调用都不应该是这样。在后台执行查询并在主线程的视图中更新结果。 – soulshined

感谢您的评论。在应用程序本身中，我确实将所有任务推送到了后台。当然，从性能角度来看，这会让事情变得更慢。我担心的关键是执行查询所需的时间 - 按照我的示例。在我的应用程序中，屏幕在用户导航时呈现动画效果，动画很差，因为查询结果时间太长。作为Parse用户，您是否有关于本地数据存储查询时间的任何信息？特别是与Coredate相比？ – pyrrhoofcam

您不在后台线程中执行查询，如上所述。而不是使用'findObjects'使用[findObjectsInBackgroudWithBlock]（https://parse.com/docs/ios/api/Classes/PFQuery.html#//api/name/findObjectsInBackgroundWithBlock :)然后当你用数组填充你的表视图时确保你正在主线上做这个部分。大量的教程，甚至在SO上。 – soulshined

解析现在是开源的，所以我对此进行了更深入的研究。这是我的发现。

解析构建一个按顺序执行的顺序执行的任务队列。这与请求的形式无关（前台，后台或带回调的背景）。任务从队列中被处理，本质上需要大约几百毫秒才能完成任务，为任务创建一个线程，然后执行所述任务。请注意，列表中的下一个任务在上一个任务完成之前不会处理。因此，如果您推动大量任务进行快速解析，那么这些任务将排队等待，您将看到时间随着任务数量的增加而线性增长。这里是一些实验代码：

PFQuery* query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 1 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 1 finished"); 
}]; 
query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 2 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 2 finished"); 
}]; 
query = [PFQuery queryWithClassName:ANNOTATION_OBJECT]; 
[query fromLocalDatastore]; 
[query orderByAscending:CREATED_FIELD]; 
NSLog(@"Query 3 started"); 
[query findObjectsInBackgroundWithBlock:^(NSArray *objects, NSError *error) { 
    if (!error) 
     NSLog(@"Query 3 finished"); 
}];

所以3个查询被推送快速连续解析。他们排队，以便查询3需要3倍的时间才能完成的查询1

2015-09-23 14:29:28.419 MvBii[257:59781] Query 1 started 
2015-09-23 14:29:28.420 MvBii[257:59781] Query 2 started 
2015-09-23 14:29:28.421 MvBii[257:59781] Query 3 started 
2015-09-23 14:29:28.658 MvBii[257:59781] Query 1 finished 
2015-09-23 14:29:28.854 MvBii[257:59781] Query 2 finished 
2015-09-23 14:29:29.011 MvBii[257:59781] Query 3 finished

对于我的应用程序，几百毫秒的查询时间正要确定，但作为用户导航的请求将堆积起来意味着排队结束的人需要很长时间。这不是不合理的解析，但应该意识到这是它的表现。如果在此任务中间存在销钉或保存，则查询将延迟销钉或保存时间的长度。这可能是几秒钟。

Parse提供了很多免费的功能，请注意，如果您连续快速请求很多，您可能会看到一些性能问题，这取决于您的应用和您的需求。

来源

2015-09-23 16:31:58 pyrrhoofcam

解析本地数据存储性能

回答

相关问题