Core Data Performance w/ long list
Core Data Performance w/ long list
- Subject: Core Data Performance w/ long list
- From: Jeff LaMarche <email@hidden>
- Date: Thu, 29 Dec 2005 10:26:52 -0500
I'm playing around with creating a simple NNTP news reader in order
to solidify both my Core Data and my network sockets programming
kills. I'm having a significant performance issue when it comes to
storing a server's list of groups. Currently, each group is a
separate entity inserted into a to-many relationship on the Server
entity. The group list on a typical Usenet server is very large
(60,000 - 300,000).
At the point where the list is done downloading (in a thread) and I
save the context (on the main thread because it seems to crash if I
do it in the thread), the UI freezes for a significant period of time
- 30 seconds or more. I've experimented with changing the store type
with no appreciable difference. I've also tried doing periodic saves
to the context that stores the server information, which helps some,
but the final save (after I insert the objects into the Server's to-
many relationship) is still horrible, and if I insert them into the
relationship as I create them, then the interface bogs down horribly
and the user can't do anything at all if the groups list is visible.
So, I need to look at fixing this. I see a couple of possible options -
1) Is there a way to save the context not on the main thread?
2) Should I store the newsgroup list as a large string or binary
attribute and just parse it into an array when necessary? This is
what I'm thinking might be the best option, though it doesn't feel
very "core-data-ey".
3) I could hide the groups list (or detach it from the array
controller temporarily) while downloading the groups and/or do
periodic inserts and saves of smaller quantities (say, 5000 items).
I'm hesitant to do this, though, because I support multiple servers,
and I'd like the user to be able to view another server's group list
while downloading.
Has anyone done anything similar and have any tips for dealing with
such a large amount of data? Since I really only need a group entity
for their subscribed lists, and not the entire groups list, I'm
thinking option 2 is my best bet, but wanted to see if anyone had
thought of a better way of dealing with this.
Thanks much,
Jeff
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden