I put up some initial docs on the components available in Wonder's Ajax framework to try to address some of the "documentation gap". It's just the initial pass, and there's obviously more that can be done. Anything that is explained in Scriptaculous or Prototype docs, for instance, is not further
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
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 sec
Sorry to reply to my own post, but for those who are interested I
have put a section on the WikiBook "Controlling Enterprise Object
Serialisation" covering this point.
Is it possible to get the EOEnterpriseObject serialiser for
WebServices to also include the GID for to-one relationships in
Is it possible to get the EOEnterpriseObject serialiser for
WebServices to also include the GID for to-one relationships in the
serialisation?
___
Andrew Lindesay
www.lindesay.co.nz
___
Do not post admin requests to the list. They will be ignored
Yes that was the comparison I was looking for --- the first two are
really the test, the 3rd i threw in just out of curiosity with the
caveat that there's not enough data to know if it's just .length that
it slow or whether there's a substantial overhead just traversing
"one more keypath".
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 PROTE
Am 22.05.2006 21:51 Uhr schrieb "Mike Schrag" unter
<[EMAIL PROTECTED]>:
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
"va
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 "publi
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 valueForKe
10 matches
Mail list logo
