Re: Cocoa bindings performance
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