• 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: Cocoa bindings performance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa bindings performance


  • Subject: Re: Cocoa bindings performance
  • From: Niels Meersschaert <email@hidden>
  • Date: Sat, 8 Apr 2006 15:36:30 -0400

mmalc,

I appreciate your help trying to troubleshoot this. I'd reviewed that earlier hoping to find some big difference in fetch performance, but in both cases the sql debug statements are identical for the relationships. The only exception is my workaround code produced this prior to the relationship debug statements:

CoreData: sql: pragma synchronous=normal
CoreData: sql: SELECT TBL_NAME FROM SQLITE_MASTER WHERE TBL_NAME = 'Z_PRIMARYKEY'
CoreData: sql: SELECT 0, S.Z_PK, S.Z_OPT, S.ZNAME, S.ZMODIFIEDDATE, S.ZPERSISTENTID, S.ZPLAYCOUNT, S.ZYEAR, S.ZRATING, S.ZARTIST, S.ZGENRE FROM ZSONG S
CoreData: annotation: fetch execution time: 0.058765s


Once that is complete, I take the returned array & run:

[results valueForKeyPath:@"@sum.field"] which immediately gives me the sum count in less than half a second.

This was followed by a series of relationship lookups identical in both cases.

A similar debug statement occurred later in both cases, probably when the bindings tried to get the sum lookup:

CoreData: sql: SELECT 0, S.Z_PK, S.Z_OPT, S.ZNAME, S.ZMODIFIEDDATE, S.ZPERSISTENTID, S.ZPLAYCOUNT, S.ZYEAR, S.ZRATING, S.ZARTIST, S.ZGENRE FROM ZSONG S
CoreData: annotation: fetch execution time: 0.056958s


CoreData: sql: SELECT 0, S.Z_PK, S.Z_OPT, S.ZNAME, S.ZMODIFIEDDATE, S.ZPERSISTENTID, S.ZPLAYCOUNT, S.ZYEAR, S.ZRATING, S.ZARTIST, S.ZGENRE FROM ZSONG S
CoreData: annotation: fetch execution time: 0.055517s


However, under the bindings version this last statement had a 3:13 delay till the next one. My assumption is it was effectively running the same [results valueForKeyPath:@"@sum.field"] as I did earlier, but when I ran it it took less than half a second instead of over 3 minutes. I put a NSLog statement in the valueForKey method for the entity to confirm this (of course, logging adds additional overhead, so I only compare performance with the logging disabled).

I can appreciate that hitting the fault can be expensive with key- value coding. To test whether it was the act of me generating a fetch request, or the key value coding performance I tried two passes with just the initial [results valueForKeyPath:@"@sum.field"] commented out, while still running the fetch request. If that was commented out, it was slow again, so it seems me calling valueForKeyPath earlier is the deciding performance factor. However, I would expect the operation would be just as expensive whether I get the valueForKeyPath or bindings does. Also this performance headache only involves key paths involving an operator like @sum. The UI does bind in the entire dataset into a table with each attribute listed. If I eliminate the @sum binding performance is speedy loading everything.

Thanks again for your input,

Niels

On Apr 8, 2006, at 2:08 AM, mmalcolm crawford wrote:


On Apr 7, 2006, at 12:07 PM, Niels Meersschaert wrote:


On Apr 7, 2006, at 12:07 PM, Niels Meersschaert wrote:
I got the entity from the context, fetching all objects & then got the sum of the field looping thru all of the entities in the returned array. When I do this, the file loads immediately & the bindings show the correct data for each @sum field. Why the dramatic difference in performance?

<http://developer.apple.com/documentation/Cocoa/Conceptual/ CoreData/Articles/cdPerformance.html#//apple_ref/doc/uid/ TP40003468-SW3>

That's a good resource that I've looked at, but my question is why is there a difference in performance accomplishing the same lookup.

The article answers that question. The lookup is not the same. Try "Analyzing Fetch Behavior with SQLite" (previous section the article).

mmalc


_______________________________________________ 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: Cocoa bindings performance
      • From: Scott Anguish <email@hidden>
References: 
 >Cocoa bindings performance (From: Niels Meersschaert <email@hidden>)
 >Re: Cocoa bindings performance (From: mmalcolm crawford <email@hidden>)
 >Re: Cocoa bindings performance (From: Niels Meersschaert <email@hidden>)
 >Re: Cocoa bindings performance (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Re: Problem with displaying drawer in doc-based app
  • Next by Date: validateDrop in NSTableView never called
  • Previous by thread: Re: Cocoa bindings performance
  • Next by thread: Re: Cocoa bindings performance
  • Index(es):
    • Date
    • Thread