• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data performance [Re: Knowing when a NSArrayController is ready]


  • Subject: Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
  • From: Ben Trumbull <email@hidden>
  • Date: Mon, 26 Jan 2009 21:23:06 -0800

poor hijacked thread.

You cannot ask -executeFetchRequest: to either filter (by predicate) or sort (by sort descriptor) based on a transient or unmodeled property.

The table view and array controller can happily sort or filter in memory. Performance on sorting large data sets in memory leaves much to be desired. However, if you must, you can strip off the sort descriptor before the fetch by using a subclass of NSArrayController (the methods to override are in NSObjectController.h) and then use the NSArray methods to handle the sort descriptor in memory.

There are many derivations of that technique, frequently having both "sort string" and "display string" property. There is an ADC sample project about string Unicode normalization so you can use a search with an index even against complex internationalized text.

<http://developer.apple.com/samplecode/DerivedProperty/index.html>

For simple stuff, just drop the predicate or sort descriptor and process the results in memory. For larger data sets, use some persistent data as a "bounding rect" in a view clipping kinda way, so the final in memory processing only touches up the results instead of working with all of them.

- Ben

On Jan 26, 2009, at 8:53 PM, Dave Fernandes wrote:

I don't mean to hijack this thread, but I have had a related (?) problem where a transient String attribute is derived from a persistent Binary attributed (an archived NSAttributedString). When my NSTableView sorts on this column, and I modify a managed object displayed in the table, I get an error in the console:

2009-01-26 23:31:53.039 MyApp[414] *** NSRunLoop ignoring exception 'unresolved keypath: referenceString' that raised during posting of delayed perform with target 15f7e2e0 and selector 'invokeWithTarget:

The table view, however, *is* able to sort on this attribute when I click the column header. Is sorting on transient attributes not fully supported?

Dave


On Jan 26, 2009, at 5:19 PM, Ben Trumbull wrote:


On Jan 26, 2009, at 2:09 PM, email@hidden wrote:

I was wondering about this - especially as I am occasionally getting a curious EXC_BAD_ACCESS when rebuilding my NSAttributed string (but that's another post).
To me appear that there are 3 ways to do this:

1. make the string rep after the fetch.
2. cache it in the db as you say.
3. use an NSValueTransformer in the binding.

Also, don't underestimate the power of writing your own custom NSValueTransformer. The default one used by transformable attributes is NSKeyedArchiver, but while flexible and powerful, it can be a bit slow for very small items.


The RTFD is more or less static so maybe caching it in the db is the simplest and has the same memory footprint as the build on fetch approach.


Caching in the db will provide a much better in memory footprint, at the expense of more disk use, and potentially slower saves.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


References: 
 >Core Data performance [Re: Knowing when a NSArrayController is ready] (From: Ben Trumbull <email@hidden>)
 >Re: Core Data performance [Re: Knowing when a NSArrayController is ready] (From: email@hidden)
 >Re: Core Data performance [Re: Knowing when a NSArrayController is ready] (From: Ben Trumbull <email@hidden>)
 >Re: Core Data performance [Re: Knowing when a NSArrayController is ready] (From: "email@hidden" <email@hidden>)
 >Re: Core Data performance [Re: Knowing when a NSArrayController is ready] (From: Ben Trumbull <email@hidden>)
 >Re: Core Data performance [Re: Knowing when a NSArrayController is ready] (From: Dave Fernandes <email@hidden>)

  • Prev by Date: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
  • Next by Date: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
  • Previous by thread: Re: Core Data performance [Re: Knowing when a NSArrayController is ready]
  • Next by thread: Does somebody know good tag-editor implementation?
  • Index(es):
    • Date
    • Thread