Hi Roland, in fact indices table exists (for DDArticle entity): Enter SQL statements terminated with a ";" sqlite> .tables ZDDARTICLE Z_METADATA Z_PRIMARYKEY sqlite> .indices ZDDARTICLE ZDDARTICLE_ZMESSAGEID_INDEX ZDDARTICLE_ZPARENT_INDEX
With my macbook pro insertion of 30k articles took about 2/3 minutes. I've uploaded a test project: http://dl.dropbox.com/u/103260/CoreDataTreeTest.zip I really don't know why it should take this long time but using Instruments the big part is obviously fetch for searching id and parent. On Sat, Feb 13, 2010 at 2:53 PM, Roland King <r...@rols.org> wrote: > > .. oh and one other thing, there's a core data instruments tool in XCode, > well there is for OSX, not for iPhoneOS which I develop for which may be why > I never saw it before. You could try that. > > On 13-Feb-2010, at 9:36 PM, Roland King wrote: > > > ok, I don't see anything wrong with the predicate code, but I'm no core > > data expert. > > > > I'll make one totally challengable statement. Assuming that core data uses > > sqllite in a rational way to store objects (eg not storing everything as > > blobs of opaque data) for instance one table per entity where each column > > of the table is an attribute and evaluating the predicate does what you > > would expect it to do, ie uses SQL to do as much of the heavy lifting on a > > fetch request as possible, that column is indexed in the table and sqllite > > is using the index; taking multi-minutes to find one row out of 20,000 just > > doesn't make any sense, it should take seconds at most. > > > > I believe core data does use table-per-entity. I think that partly because > > the documentation hints at it, partly because it makes sense and partly > > because I looked at the implementation of one data model that I have. > > > > I can't see the point of making indexes if the predicate code doesn't > > generate SQL which doesn't use them, but it's possible. It's possible that > > core data goes and loads all the entity rows and inspects their attributes > > by hand and filters them in code, but this is apple not microsoft. > > > > So that leaves column isn't indexed as the most likely. But you've checked > > the 'indexed' box. Here's another wild assed guess, does coredata only > > create a store when you have no current store? It certainly checks to see > > if the store is compatible with the model but as the indexed property is > > just a hint anyway, that store is compatible, just non-optimal .. it's > > possible if you created the store with the property defined as not-indexed > > and have just checked that box later, without regenerating the whole store, > > the index was never added. Did you do that, just check it later? Have you > > regenerated a complete new store since or are you using a store you've been > > populating for a while. > > > > Here's a particularly ugly idea, purists please stop reading now. We can > > look at the store and see if it has an index on that property ... first get > > up a terminal window and go to the path where your store is. I'm assuming > > you have sqlite3 installed like I do .. it came with the OS as far as I > > know. > > > > Your store should be called something.sqlite, let's say it's Foo. Type > > > > sqlite3 Foo.sqlite > > > > and that should open the store and give you a prompt. First you want to > > find the tables in the store, so type > > > > .tables > > > > as far as I can see they are called Z<YOUR ENTITY NAME>, so for you I'd > > expect to see one of the tables called ZMCARTICLE. If there is one, you can > > find out what indices are on it > > > > .indices ZMCARTICLE > > > > I believe again the indices are called Z<YOUR ENTITY NAME>_Z<YOUR ATTRIBUTE > > NAME>_INDEX, so you'd expect to find ZMCARTICLE_ZMESSAGEID_INDEX in that > > list. If you don't have it, the store wasn't created with that index. If > > none of those tables exist at all, my rudimentary reverse engineering of > > the whole coredata thing is flawed (or I'm using some entirely different > > version from you). > > > > If the tables and indices exist, including the one on ZMESSAGEID, I'm out > > of ideas unless someone knows of a way to put coredata into a form of debug > > mode and see the SQL generated to figure out if it's doing anything smart. > > > > If either none of the above works or it does work but you don't have the > > index, you have a couple of options. The right one is to delete your whole > > message store and run your app and make a brand new one to see if that then > > adds the indexed property with an index. Depending on how you've populated > > the store, that might be a real pain, perhaps you can force a migration or > > something. The other really stupid idea would be to just add the index and > > hope that doesn't break everything entirely which is entirely possible at > > which point you delete the store and start over. You would do that by > > running > > > > CREATE INDEX ZMCARTICLE_ZMESSAGEID_INDEX ON ZMCARTICLE (ZMESSAGEID); > > > > Here's another useful thing I just came across, I would certainly run this > > to see if the SQL being executed makes sense. > > > > > > With Mac OS X version 10.4.3 and later, you can use the user default > > com.apple.CoreData.SQLDebug to log to stderr the actual SQL sent to SQLite. > > (Note that user default names are case sensitive.) For example, you can > > pass the following as an argument to the application: > > > > -com.apple.CoreData.SQLDebug 1 > > Higher levels of debug numbers produce more information, although using > > higher numbers is likely to be of diminishing utility. > > > > > > > > I'd love to hear about any other ways people have to debug coredata. I sort > > of trust apple has done a good job with it and for it to break down > > performance wise on looking for a row in 20,000 with a certain attribute > > doesn't make sense to me. If you really can't get it to work, I'd write a > > short project which inserts 20,000 simple objects into a store and another > > one which opened the store and goes looking for one by attribute in the way > > you have. If it takes multi-minutes, I'd sent it to apple as a bug. _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
