Re: Is NSEntityDescription insertNewObjectForEntityForName:inManagedObjectContext: this slow?
Re: Is NSEntityDescription insertNewObjectForEntityForName:inManagedObjectContext: this slow?
- Subject: Re: Is NSEntityDescription insertNewObjectForEntityForName:inManagedObjectContext: this slow?
- From: Javigator <email@hidden>
- Date: Tue, 19 Jul 2005 09:54:37 +0200
Am 19. Jul 2005 um 09:37 schrieb mmalcolm crawford:
On Jul 19, 2005, at 12:07 AM, Javigator wrote:
The entities can show up in a NSTableView (12 columns) powered by
an NSArrayController preparing the CoreData entities for it, but
is depended upon a master table (via binding the contentSet binding).
Now, when the contentSet binding is set to a master where no
detail data (= relationship objects) exists, and the app creates
the 600 objects as described above, it takes its time (> 40 sec.).
When the detail table shows the relationship of another object and
the master currently getting the detail data is different, it
doesn't take more than 2 sec...
Then the application is presumably doing a lot of (largely
unnecessary) user interface update..?
Cannot say that. The table stays empty for the time the objects take
to create. The rows show up all at once when the creation has
finished. There's not much into bindings as well, only the table
columns are bound to the NSArrayController. The only thing I now can
think of are three custom value transformers, but at the first glance
they don't seem very time consuming (one does some date/time
calculation, one is displaying a 200 bytes image in a column for a
bool value cannot brake this muc, can it?). Maybe I should remove
them and test again.
Rather than setting a to-one relationship one object at a time, why
not wait until the end of the loop then add all the new objects to
the destination's to-many relationship?
Did a test run on that, too. Doesn't matter, at least not noticeable.
mmalc
Thanks for your input! :-)
Best regards,
Joern Janoschek.
_______________________________________________
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