In general, I agree with what’s been said so far. About performance:
For the size of the object collection being described, I would tend to think that the overhead of keeping track of it shouldn’t be a major factor, no matter how you go… modern Mac’s and iOS devices have more than enough CPU power to make it disappear in the noise. What you do with it will dominate the performance of the resultant app - using a screaming fast record management system, collating high-resolution medical images and doing feature recognition on them is going to run a lot slower than a recipe list app that uses a dog slow record management system, for example. However, in absolute terms, a custom-tuned solution will outperform a runtime-flexible general purpose solution like Core Data (and SQLite, which it’s usually running on top of). Assembling fetch requests takes resources (CPU, memory, and battery), and because they are interpreted they are slower than pre-compiled fetch operations. For example, suppose that I have a bunch of interestingObjects and I want to fetch them from file storage by UUID; and I want to do this as fast as possible (all other concerns being secondary). The strategy that I think I would take is to create two files, one with a hash table of the UUIDs and offsets into the second file, which contains the serialized storage of the interestingObjects (and for maximum speed, I would forgo portability in favor of just keeping a binary image of the interestingObjects if possible: i.e, write raw structs to disk). I would also think about mmap-ing the files into my address space to eliminate read() and write() calls. This would yield the bare minimum overhead to accomplish the goal; at the cost of flexibility and portability (and potentially development time, depending on how much difficulty one encounters adapting a general purpose solution to the specific problem, and how adept one is at doing this sort of raw data structure manipulation). For Core Data to do the same thing, it must parse the data model, construct search predicates, translate them into SQL, and hand that off to SQLite; which must in turn parse the database structure and “compile” the SQL into an actionable set of search operations, interpret that to perform the search, assemble the results into it’s buffers, and hand that back off to Core Data; which must then translate the SQLite buffers into managed objects (again, parsing the data model), and only then can it return the result. Oh, and it’s got error checking at every step also. The direct approach requires calculating a hash (for a UUID, that might be as simple as xor-ing the bytes up as 32-bit ints, and doing a modulo operation to fit the result to the size of the hash table - but, I have not profiled that myself, so I can’t necessarily recommend it - it’s just an example), performing some small number of comparisons (ideally, only 1, in the case of a hit on the first hash table bucket), and a bit of pointer arithmetic to get the location of the storage of the desired object; and doing whatever minimal construction is required to turn that stored struct into an actual live interestingObject - much less complexity than what Core Data (or any general-purpose system) goes through. Before making any commitments, I would profile all of the choices available to you - the above discourse is just a general overview of things; and details (and optimizations) matter. Sometimes, the profiler turns up the darnedest of results… :-) _______________________________________________ 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
