核心数据对象插入循环导致NSNumber *属性对内部循环中的对象小说的问题 [英] core data object insert in loop causes problems with NSNumber* property on object novel in inner-loop

查看:118
本文介绍了核心数据对象插入循环导致NSNumber *属性对内部循环中的对象小说的问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个循环,其性能降低,因为它继续(第一个循环可能是3秒,最后可能是400超过500次迭代)。我把它缩小了一行代码。 。 。将唯一的NSNumber值附加到核心数据对象。目录大小通常为20K-150K。

I have a loop that has degrading performance as it proceeds (the first loop might be 3 seconds, the last might be 400 over 500 iterations). I've narrowed it down one line of code . . . attaching a unique NSNumber value to a core data object. The catalog size is typically 20K-150K.

这是在外部循环中运行的摘录。外部循环由于一行代码而变得越来越慢:

Here is the excerpt that runs in an outer loop. The outer loop gets slower and slower each time due to one line of code:

for(int i = 0 ; i < 500 ; i++){
  NSString *key = @"somerandomstring" ; 
  NSNumber* sampleIdNumber = [NSNumber numberWithInt:13] ;
  for (it = catalog.begin(); it != catalog.end(); it++) {
    // it->second->id changes each time in the inner-loop
    NSNumber* tagNumber = [NSNumber numberWithInt:it->second->id];
    DatumMO *newDatumMO = [NSEntityDescription insertNewObjectForEntityForName:@"Datum" inManagedObjectContext:moc];

    // **TagNumber changes each inner loop**
    // **Each time outer loop is calculated it gets slower**
    // **This does not happen if tagNumber is constant**
    newDatumMO.tagId = tagNumber ;

    newDatumMO.name = key;
    newDatumMO.sampleId = sampleIdNumber;
 }
}

另外几点:ARC代码,autoreleasepool循环,但没有什么区别。 'tagId'和'sampleId'都是我的核心数据数据模型中的Integer32。

A few other points: ARC code, autoreleasepool defined around loop, but doesn't make any difference. 'tagId' and 'sampleId' are both Integer32 in my core data datamodel.

到目前为止,我尝试了:
- 将tagId重定义为int32_t更改)
- 使用STL映射预定义NSNumber *并执行查找(无更改)
- 分配tagId常量(修复问题,但不正确)
- 分配一个随机int tagId它更糟,当然)

What I've tried thus far: - redefine tagId to int32_t (no change) - use STL map to predefine NSNumber* and do a lookup (no change) - assign tagId constant (fixes problem, but not right) - assign a random int tagId (make it worse, of course)

这似乎是接近的,但不清楚这是否是实际的问题,或者这是目前处理核心的最佳实践-数据。

This seems to be close, but it is unclear if this is the actual problem or if this is currently the best practice for handling scalars in core-data.

http ://blog.lorentey.hu/2010/10/31/core-data-scalars/

UPDATE 1
我实现了上面链接中描述的标量模型,行为没有改变。去运行进一步的仪器。 CPU变得饥饿(最初是固定的),并且内存是不变的,所以它是交换/加载内存到超过它需要的内存,或者写入核心数据减慢它。调整核心数据写入频率在这种效果上没有差别(虽然明显影响性能)。删除autoreleasepool调用在这个过程中也产生明显的效果。去尝试切换到使用NSString * next,因为我的想法。

UPDATE 1 I implemented the scalar model described in the above link with no change in behavior. Going to run further instrumentation on it. The CPU gets starved (is pegged initially) and memory is constant, so either it is swapping out / loading stuff into memory more than it needs to, or writes to core-data slowing it down. Adjusting the core-data write frequency yields no difference in this effect (though obviously effects performance). Removing the autoreleasepool calls also yields obvious effects in this process. Going to try switching to use NSString* next as I'm out of ideas.

推荐答案

Duh,DatumMO.tagId是一个索引列(如sampleId)。显然,如果我创建100K独特,索引插入看起来导致显着减慢,因为插入数量上升(必须在某处进行线性扫描?)。不确定是否会提供足够的加速,或需要进行后加载索引,自定义或其他方式,但这是另一个问题。

Duh, DatumMO.tagId is an indexed column (as is sampleId). Obviously if I'm creating 100K unique, indexed inserts appears to cause significant slow-down as the number of inserts goes up (must be doing a linear scan somewhere?). Not sure if it will provide sufficient speedup or will need to do a post-load indexing, custom or otherwise, but that is another question.

这篇关于核心数据对象插入循环导致NSNumber *属性对内部循环中的对象小说的问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆