Re: Need help building an EOQualifier with session values
Re: Need help building an EOQualifier with session values
- Subject: Re: Need help building an EOQualifier with session values
- From: Ken Anderson <email@hidden>
- Date: Mon, 22 May 2006 16:29:13 -0400
I think the test is reasonably valid - the question being tested was,
is there a penalty for always using valueForKeyPath(). Under what
circumstances would you not want to?
On May 22, 2006, at 4:27 PM, Wolfram Stebel wrote:
Am 22.05.2006 21:51 Uhr schrieb "Mike Schrag" unter
<email@hidden>:
Hello Mike,
i dont think that that your arguments for "use always key path" are
valid.
I think there is a difference in calling "length" as a method on
String
instead of following a relation, a more important reason that
"valueForKeyPath" exists. I think, there will be a time difference
too, when
you access an EO-member function instead of "length".
Though I never tested....
Am I right?
Wolfram
Technically speaking, you can ALWAYS use valueForKeyPath and it will
work. Obviously valueForKey does not have that attribute.
So the question is performance ... I've kind of wondered this before
also. So in the spirit of knowing-is-half-the-battle:
I have an object with one method "public String getName()" and ran
one million iterations of the following:
NSKeyValueCoding.Utility.valueForKey "name": 935ms
NSKeyValueCodingAdditions.Utility.valueForKeyPath "name": 992ms
NSKeyValueCodingAdditions.Utility.valueForKeyPath "name.length":
2713ms
That's total time for all 1 million. So basically no diff using
keypath vs key -- i would say always use it. I included the next one
just because it was kind of interesting. Obviously there aren't
enough examples to know if that's a function of the performance
of .length() on String or whether traversing multiple keypaths is
nasty.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40anderhome.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden