On Apr 8, 2014, at 18:09 , Graham Cox <graham....@bigpond.com> wrote:
> > 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. Thanks for that data point, Graham. My app is very similar in this regard to yours, and that's exactly how I was thinking of treating it. On Apr 8, 2014, at 17:31 , BareFeetWare <list.develo...@barefeetware.com> wrote: > One option is to use SQLite. I've been putting together an open source > "BFWQuery" library to hopefully simplify the whole thing, by letting you > treat a database query just like an array of dictionaries. It uses FMDB > (thanks Gus). Well, if I were to do this, one of the reasons would be to create a text representation that could be easily diffed. I took a look at Core Data's XML format, and while necessarily verbose, it would work pretty well, until the schema changed. -- Rick
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
