2016-09-27 6 views
0

非常に遅いコードがいくつかあります。問題を次の行に絞りました。コメントアウトすると、コードは急速に実行されます。このプロセスには、コンパイラまたは実行時にエラーが報告されることはありませんが、30秒以上かかる場合があります。IOS/Objective-C:nullのテスト日が非常に遅い

次のように私は一時オブジェクトの日付を持っている:私は、コンソールにこれをログインした場合

NSDate *lastedited = importObject.lastedited; 

それはとして記録します。

2015-10-08 08:44:51 +0000 

上記は、遅延

が発生することはありません。

その後、Core Dataに保存すると、まずnullであるかどうかを確認します。

if (lastedited != (id)[NSNull null]){ 
    [record setValue:lastedited forKey:@"lastedited"]; 
} 

EDIT:しかし、次のコードは、極端な遅延原因です

をしても、テスト、非常にゆっくりと走る[record setValue:lastedited forKey:@"lastedited"]行を取り出すことを私が発見しました。

これは、エンティティのlasteditedがデータモデルのNSDateであるという事実にもかかわらずです。

そして、一番上の行は、それが2015-10-08 08:44:51 +0000

としてコンソールにNSDateとログの形式であることを示しているよう誰も私のコードは非常にゆっくりと実行する原因になっているかを把握助けることができますか?

ありがとうございます。

+0

コアデータエンティティの最後のフィールドのデータタイプは?それはNSDateかNSTimeIntervalですか? – Arun

+0

コアデータファイルの.hファイルのNSDateとModel.scdatamodeldで表示 – user6631314

+0

* slow *の速度はどれくらいですか? – vikingosegundo

答えて

0

nilに対して単純にテストしているわけではありませんか?私は問題があなたのCoredataエンティティにおけるlasteditedフィールドのデータ型であると思いhttp://nshipster.com/nil/

0

if (lastedited != nil) { 
    .... 
} 

は、ここでのObjective-C/Cocoaの中には何もの異なる種類の良い概要です。使用しているデータタイプはNSDateですが、もちろんCoredataでサポートされているプリミティブデータタイプではありません。データ型が(int、float、double、String、NSTimeIntervalなどの)プリミティブ型のいずれでもない場合、Coredataは最初にそれをプリミティブ型の1つに変換します。あなたのケースでは、保存する直前に日付がNSTimeIntervalに変換されます。これは処理が大変で、予想よりも時間がかかります。したがって、NSDateを保存する前にNSTimeIntervalに変換するオーバーヘッドを実行している場合は、処理が高速になります。試してみてくださいこの

[record setValue:([lastedited timeIntervalSince1970] * 1000) forKey:@"lastedited"]; 

は、エンティティの.hファイルにNSTimeIntervalにlasteditedのデータ型を変更することを忘れないでください。

@property (nullable, nonatomic, copy) NSTimeInterval *lastedited; 

ここで、日付をミリ秒単位で保存することに注意してください。したがって、コアデータからフェッチするときはいつでもNSDateに変換して使用してください。

+0

[docs](https://developer.apple.com/reference/foundation/nsdate):* NSDateオブジェクトは、特定のカレンダーシステムまたはタイムゾーンとは関係なく、単一の時点をカプセル化します。 Dateオブジェクトは不変であり、絶対参照日付(2001年1月1日00:00:00 UTC)に対する不変の時間間隔を表します。*概念的なNSDateは、時間間隔の周りの軽いラッパーです。だからあなたの提案は実行時間を大幅に改善するとは考えにくいです。 – vikingosegundo

関連する問題