優化批量刪除和創建NSManagedObjects

當用戶下載我的應用程序並'註冊'時，我們用核心數據填充用戶數據，這可能會潛在成千上萬的對象。優化批量刪除和創建NSManagedObjects

我們還爲用戶提供「註銷」選項，在此時我們批量刪除這些對象。（我們不會刪除底層的sqlite商店，因爲那裏的一些數據不是用戶特定的，我們希望保留這些）。

在批量創建和刪除中常見的是這些過程花費了大量時間。

進行明顯的優化和使用時間輪廓儀後，我到達的最大瓶頸似乎是這種模式的結論：

- (void)awakeFromFetch { 
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(someSelector:) name:someNotification object:nil]; 
} 

- (void)didTurnIntoFault { 
    [[NSNotificationCenter defaultCenter] removeObserver:self]; 
}

這似乎是服用65-70％的所有的CPU時間在創建和刪除過程中。我試圖儘量減少在創建時受到傷害的對象的數量，但是有一個我不能進一步降低的最小數量。

但是對於刪除，看起來標記爲被刪除的對象必須被獲取，無故障並且再次發生故障，因此didTurnIntoFault被調用以用於所有被刪除的對象。我在didTurnIntoFault中執行了大部分對象清理，但令人驚訝的是，從默認的NSNotificationCenter中以觀察者身份移除對象似乎是最重的操作（大幅度）。

任何想法爲什麼removeObserver：變得如此沉重？有關如何優化此更快註冊/註銷的想法？

來源

2014-02-08 Apoorv Khatreja

爲什麼不在用戶註銷時創建新的存儲。使用種子數據保存新商店，並在用戶註銷時替換商店，而不是刪除對象。或者使用兩個存儲區，一個存儲可丟棄的用戶數據，另一個存儲您想要保留的數據，然後用空白的用戶數據替換。 –

爲什麼你甚至需要數千個物體？保持多個商店和延遲加載。 – Wain

我不確定多個商店如何在創建和刪除期間幫助我需要插入/刪除所有對象。 –

NotificationCenter是一個強大的工具，帶有一些成本。當你在沒有接收/產生對象的情況下使用它時（object:nil在你的代碼中），那麼事情可能會橫向並且開始變得昂貴。

所以我的第一個建議是通過添加一個對象來探索縮小通知的範圍。希望有一個對象拋出你收到的通知嗎？如果是這樣你能以某種方式通過它？

第二個想法是將通知完全移出NSManagedObject。這會導致更多的工作，所以這是我的第二個建議，即使我更多地推薦它。考慮讓一個控制器監聽通知，參考NSManagedObjectContext然後可以做適當的工作。

如果這兩個都不合適，那麼需要更好地理解該通知的用途。

來源

2014-02-08 17:18:08

優化批量刪除和創建NSManagedObjects

回答

相關問題