Re: method lookup order performance benefit?
Re: method lookup order performance benefit?
- Subject: Re: method lookup order performance benefit?
- From: Michael Engelhart <email@hidden>
- Date: Mon, 26 Apr 2004 12:00:38 -0500
Thanks for the reference pointer to NSKeyValueCoding API doc.
BTW, I clearly wasn't implying that the creators of WO at Next/Apple
weren't smart. Also I don't think investigating "simple" performance
optimizations that may be available by choosing one of 6 different ways
of working within the WO frameworks is a "total waste of time". I
wasn't looking it from only the performance benefit but also from the
"I need to start creating my own pattern of how to use XCode/WOBuilder
to get the best use of my time both immediately and down the road". To
me finding out that simply choosing option 1 over option 6 had a 3%
increase in performance and all I had to do was get it right the first
time instead of going back 6 months later and having to rewrite all my
getter/setter code to gain that boost is certainly worth pursuing.
This doesn't appear to be the case regarding method lookup but I didn't
know that until your post. As a new user, there is a lot to learn
and I didn't want to wind up "learning" something in the least optimal
way if it did in fact make a difference.
In "WebObjects we trust" will be my motto moving forward...
Mike
On Apr 26, 2004, at 11:11 AM, Chuck Hill wrote:
As a newbie to WO you are totally wasting your time pursuing avenues
of performance optimizations like this. WO has been around a while.
Some very smart people have worked on it. I don't think there are
many optimizations left to do that are not very application specific.
WO is not like other tools. Ignore the infrastructure. Trust that is
is good - it is! Focus on solving the business problem. The
infrastructure was done years ago.
In the docs we trust (well, when we can find them). From
NSKeyValueCoding interface:
Note: The default implementations have significant performance
optimizations. To benefit from them, NSKeyValueCoding can be
implemented on a custom class as shown above by using the methods in
NSKeyValueCoding.DefaultImplementation, or if your class inherits
from a WebObjects class that implements NSKeyValueCoding, do not
override the inherited implementation. Using a custom implementation
incurs significant performance penalties.
Chuck
On Apr 26, 2004, at 7:20 AM, Michael Engelhart wrote:
Hi -
I was looking at Apple's Inside WebObjects Web Applications
documentation last night and was reading the section on the Sync
stage of the request response cycle and noticed mention of the order
in which say takeValuesFromRequest tries to find available
setters/getters or instance variables. They list this order:
SETTERS:
1. public void setKey()
2. private _setKey()
3. _key
4. key
GETTERS:
1. public [...] getKey()
2. public [...] key()
3. private [...] _getKey()
4. private [...] key()
5. [...] _key
6. [...] key
So my question is this. Is there any performance benefit to using
the standard JavaBeans setter/getter methods since they are the first
in the chain of lookups? Not having access to the source of how WO
does this and not being hugely familiar with Reflection (which is
what I'm guessing WO uses internally to make this decision), it seems
that would be the case. But being new to WO I'm not sure. The
reason I'm even asking is that EOModeler doesn't allow you to choose
how you want the source generated. It only outputs:
key() // getter
setKey() // setter
for the generated Java class file.
Not a huge deal but would rather ( if there is a performance hit to
using method calls that are lower in the chain) just get in the habit
of rewriting out methods using the JavaBeans standard and also to
"always" create setter/getters in WOBuilder. It seems like most of
the books I have don't advise you to select the setter/getter
auto-generation for instance variables when adding them to the
example code that is being shown. It's always shown as optional.
Thanks for any insight.
Mike
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.