優化NSFetchedResultsController取

我有一個NSFetchedResultsController並存儲在覈心數據的大量數據的所述讀取的結果控制器必須取。大約有46,000件物品最終會被抓取。問題在於獲取時間超過8秒，並且整個過程中，UI被凍結，因爲我們必須在主線程上獲取。我想知道我能做些什麼來加快速度？優化NSFetchedResultsController取

我可以通過創建日期排序的對象，該找取請求具有100批量大小，且謂詞不是過於複雜。它通過UID，類型和其擁有者的UID過濾對象。

由於用戶可以搜索，抓取謂詞會改變，所以具有讀取的結果控制器上的高速緩存，似乎毫無意義，當它只是被刪除每次取謂詞的變化。

它直接關係到在覈心數據對象的數量，因爲在切換到具有較少對象的帳戶減小急劇提取時間。（6000個物體需要的時間少於一秒）。有什麼方法可以使這個更具擴展性？我的代碼如下：

- (NSFetchRequest *)getFetchRequest 
{ 
    NSFetchRequest *fetchRequest = [NSFetchRequest requestWithEntityName:@"Photo"]; 
    NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"date" ascending:NO]; 
    [fetchRequest setSortDescriptors:[NSArray arrayWithObject:sortDescriptor]]; 
    [sortDescriptor release]; 
    [fetchRequest setPredicate:[self getFetchPredicates]]; 
    [fetchRequest setFetchBatchSize:100]; 
    return fetchRequest; 
} 

- (NSPredicate *)getFetchPredicates { 
    NSMutableArray *predicates = [NSMutableArray arrayWithObjects: 
            [NSPredicate predicateWithFormat:@"life_uid == %@",[[LoginManager shared] currentLifeUID]], 
            [NSPredicate predicateWithFormat:@"(type == %@) OR (type == %@)", TLTypeImage, TLTypeVideo], 
            [NSPredicate predicateWithFormat:@"(ANY stories.permission.owner_person_uid == %@ OR [email protected] == 0)", [[LoginManager shared] currentPersonUID]], 
            nil]; 
    NSArray *filteredMomentIDs = [[self searchTerms] objectForKey:TLLibraryViewControllerSearchTermsPhotoIDsKey]; 
    if ([filteredMomentIDs count] > 0 && [self searchMode] == kTLLibrarySearchModeTag) 
    { 
     [predicates addObject:[NSPredicate predicateWithFormat:@"uid in %@", filteredIDs]]; 
    } 
    return [NSCompoundPredicate andPredicateWithSubpredicates:predicates]; 
}

來源

2013-03-01 Jacob

如果您可以添加（a）您的謂詞，以及（b）您正在搜索的字段的類型（字符串，整數等），這將有所幫助。 – 2013-03-01 17:46:38

您是否嘗試在提取謂詞中使用的屬性上設置索引？ – 2013-03-01 17:47:15

你提到你的謂詞過濾器'...他們所有者的UID'。根據我的經驗，關係可以對提取性能產生重大影響。可能值得通過刪除謂詞的部分來測試對速度的影響。 – ChrisH 2013-03-01 17:57:02

既然你解釋（在評論中）所有的屬性都是字符串，你可能很難改善情況。你做字符串比較的很多在fetch-- 46K記錄前兩個謂詞乘以至少3個，加上更多取決於有多少stories關係平均有。這是你的性能問題的主要原因 - 這樣做很多字符串比較將成爲瓶頸。

幾件事情，可以幫助：

在你看@"(ANY stories.permission.owner_person_uid == %@ OR [email protected] == 0)"第三個謂語。謂詞從左到右進行評估。數字比較比字符串比較更快，因此首先檢查@count。如果這是真的，那麼後半部分就不需要評估了，你會跳過大量的字符串比較。
從左到右的東西也適用於NSPredicate實例的順序。你可能有一些想法是什麼數據看起來like--確保該最嚴格的謂語（即一個對象將不通的最大數量）在列表中的第一個。然後是第二個限制性的，等等。由於你將謂詞連接在一起，一個實例失敗了，第一個謂詞不需要與其他謂詞進行覈對。儘可能早地在謂詞鏈中篩選出對象。

也許最簡單的收益是通過改變第三個謂詞的順序，然後將它移動到列表的前面。

來源

2013-03-02 00:18:39

我想你總是可以對數據模型進行標準化，如果這對於性能來說真的很重要。您可以將owner_person_uid屬性的副本添加到故事對象中。這樣，謂詞就不必穿越如此多的關係。

此解決方案將要求您在更改其中一個屬性時始終更新相關對象。

來源

2013-03-02 00:31:48

優化NSFetchedResultsController取

回答

相關問題