On 9 Apr 2014, at 8:13 am, Rick Mann <rm...@latencyzero.com> wrote: > As I write this, I realize that I can't just keep a whole document in memory; > the library (which would be a collection of separate files on disk, but > presented as a unified collection of content in the UI) could be very large > and I'd rather not load in the whole thing. Nevertheless, I think that's > doable.
I have no comment regarding Core Data, but just a general comment regarding this remark. This sounds very much like what I do in both our vector apps to present a collection of library items. These run to thousands of items in multiple libraries, organised into sets called categories, presented through a single UI which allows the user to organise them and use them. We don't load the whole collection into memory, though we do have an in-memory representation of that collection which tracks the location of the original file and an image (and other metadata) representing the item. The UI shows that image which is loaded lazily and on a secondary thread, so the UI remains responsive even when scrolling through thousands of items. If the user wants to incorporate a library item into their document, then the "real" item is loaded at the point of use, and occupies memory from then on. Point is: we've never run into memory or performance issues with this. I guess at some point stuff could well get paged out but we don't do anything to prevent that. In practice, I've rarely noticed delays caused by that occurring, and typically it's been because of another foreground app needing to page its stuff in. In many cases I would imagine that the image we load (a pdf) is actually larger than the real data - but even then it's still not a practical problem. So far we've seen no scalability issues up to the order of tens of thousands of items - how large is your library likely to be? 10,000 different vector objects is actually a pretty large number. Again, in practice the way this is used is that a user often filters that down to a small set of items they need for a project (they can build their own categories, collections and "smart" sets based on predicates) - an entire collection can be overwhelming - and stuff that's never browsed never even loads the image and metadata, so the reality of the in-memory copy is that it's actually a small subset of what out there on disk almost all of the time. So yes, it's doable - we've done it and it works fine. Unless your needs are significantly larger than this, I wouldn't sweat the memory requirements at this stage. Our scheme doesn't use Core Data. It probably could, but I've never been totally sold on it personally. --Graham _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
