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: Mike Schrag <email@hidden>
- Date: Tue, 23 May 2006 01:08:20 -0400
Good catch ... You are correct that it was actually returning a
constant value and probably was being JIT'd away. I'm on a 2Ghz
MacBook Pro, by the way.
Here are the results of the slightly modified test that returns
constant string + System.currentTimeMillis() AND uses -Xint to
disable Hotspot. Prepare yourself for Java circa 1998 :)
LoadData.main: NSKeyValueCoding.Utility.valueForKey "name": 12635ms
LoadData.main: NSKeyValueCodingAdditions.Utility.valueForKeyPath
"name": 13840ms
Two things here 1) holy crap that's slow with no JIT :), and 2)
there's about a 10% performance difference -- interestingly PRETTY
close to the relative difference in the JIT'd one with constants,
which I would not have guessed. Not sure what that says exactly :),
but interesting nonetheless. At the end of the day, though, I have a
sneaking suspicion that with as much as these methods get called
during every single request in your WO app by the frameworks, the
handful of times you call it manually probably isn't going to make or
break your app's performance. If you have a case where you KNOW you
only have one key in a path, then sure, use valueForKey. But when in
doubt, it's probably not worth losing sleep over using
valueForKeyPath, I don't think.
ms
On May 23, 2006, at 12:56 AM, Jerry W. Walker wrote:
Hi, Mike, et al,
Thanks for testing that, but I think there might be something wrong
with the test, and I suspect it might have something to do with
optimizing compilation.
From what you've said, your test is indicating that valueForKeyPath
takes( (992 - 935) / 1000) / 1,000,000 of a second longer per
execution than valueForKey. By my reckoning, that's 57 nanoseconds
extra each time valueForKeyPath is used rather than valueForKey.
You didn't mention what kind of processor you were running on, and
since we were doing a relative comparison, it would generally not
make a difference, but I have a hard time believing that the Java
Virtual Machine can execute a single JVM instruction in 57
nanoseconds. So we're probably dealing with a JIT compiler. That
would change the issue to executing native code. Is it possible on
your machine to execute a single instruction (approximately) in 57
nanoseconds?
I have the feeling that in the loop, the compiler has determined
the result we're trying to get is not changing, identified it as a
constant path for each of valueForKey and valueForKeyPath and is
caching something for us.
My (unsupported) feeling is that the 57 millisecond difference that
we're seeing from the million iterations, might be the difference
to obtain only the very first result for each approach, which is
then cached somehow and we're using the exact same approach (to
obtain a cached value) in both cases after the caching, so no more
difference.
It's late, so I'll try to set up a slightly different test tomorrow.
Regards,
Jerry
On May 22, 2006, at 3:51 PM, Mike Schrag wrote:
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.
On May 22, 2006, at 3:33 PM, Zak Burke wrote:
Chuck Hill wrote on 5/21/06 11:44 AM:
NSArray bindings = new NSArray( new Object [] {
(Session)session().valueForKey("user.client.clientName") } );
valueForKeyPath not valueForKey
I've been bitten by this one too.
Is there ever a reason to use valueForKey instead of
valueForKeyPath? (I
ask this question along the same vein as, "Is the simplicity of
always
using addObjectToBothSidesOfRelationshipWithKey worth the potential
performance hit compared to addObjectToPropertyWithKey?")
The NSKeyValueCodingAdditions documentation doesn't allude to any
performance hits, and says its basically implemented in terms of
value
for key. Is valueForKey faster? I supposed it would be because it
won't
even try to access items along the keypath; it'll just die right
away.
As an aside, is it possible for an item to have a valid key
containing a
dot? Don't keys eventually map to object properties that have to
conform
to java variable names?
zak.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.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:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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