• 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: When exactly does a fault get fired?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: When exactly does a fault get fired?


  • Subject: Re: When exactly does a fault get fired?
  • From: Chris Hanson <email@hidden>
  • Date: Fri, 17 Feb 2006 22:46:12 -0800

On Feb 17, 2006, at 8:24 PM, Andre wrote:
Thanks, I guess I could do that then. I was just worried that if I have a huge number of 'employee' entities, then performance could degrade... is that a concern at all?

I wouldn't worry about it. Especially with the kind of fetch I used above and the SQLite persistent store, you should really let the Core Data persistence stack do the heavy lifting for you. That can mean leveraging fetch requests for filtering rather than strictly measuring


Hmm, I'm wondering, if I retrieve a set of objects using KVC for a relation like [engineering mutableSetValueForKey:@"employees"] does it use the same mechanism as the fetch predicate like in your example : (department = %@), with coredata knowing 'department' is an to-many relationship... so the performance is the same? (I know we shouldn't rely too much on implementation details as they change, but its more for performance question)

Indeed, you shouldn't rely too much on implementation details. If you want to work with the objects in the relationship as objects in a relationship, you should use the relationship. If you want to work with objects meeting some criteria, even objects in a relationship, using a fetch request rather than doing the filtering yourself can make things easier and it can be easier for the framework to support you in your use. Your best bet is to always try to follow the framework's patterns first, and reserve performance optimization and doing things "by hand" for the areas where measurement shows it's necessary.


Also, I know you wanted to avoid normalizing your data model such that your large data BLOB is in a separate entity, but you really should consider it. You can put a transient BLOB attribute on its "owner" that traverses the relationship upon access, and avoid pulling the BLOB data in from the persistent store any time you don't actually need to use it. (Assuming again you're using the SQLite persistent store type.)

  -- Chris

_______________________________________________
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


  • Follow-Ups:
    • Re: When exactly does a fault get fired?
      • From: Chris Hanson <email@hidden>
    • Re: When exactly does a fault get fired?
      • From: Andre <email@hidden>
References: 
 >When exactly does a fault get fired? (From: email@hidden)
 >Re: When exactly does a fault get fired? (From: AurĂ©lien HugelĂ© <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Andre <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Chris Hanson <email@hidden>)
 >Re: When exactly does a fault get fired? (From: mmalcolm crawford <email@hidden>)
 >Re: When exactly does a fault get fired? (From: email@hidden)
 >Re: When exactly does a fault get fired? (From: Chris Hanson <email@hidden>)
 >Re: When exactly does a fault get fired? (From: Andre <email@hidden>)

  • Prev by Date: Re: Horrible documentation
  • Next by Date: Re: Horrible documentation
  • Previous by thread: Re: When exactly does a fault get fired?
  • Next by thread: Re: When exactly does a fault get fired?
  • Index(es):
    • Date
    • Thread