Oops, the numbers aren't quite as bad as I thought. The original
numbers included the cost of compiling the OGNL expression. If you
exclude the OGNL compilation the numbers are:
Using OGNL expression: 15 ms
Explicitly calling getText: 0 ms
I knew that compiling the OGNL expression took a long time, but I didn't
realize it was that long. I still think there is a benefit to updating
the way the UIBean does key lookup. At a minimum it will make the Text
and other UIBeans more consistent and there is a slight performance benefit.
I'm glad you resolved your issue. I knew about the other property, but
I normally don't set that one explicitly--so I didn't think to mention
it. :) That definitely explains the huge numbers.
Tom
David H. DeWolf wrote:
Nice, that seems in line with what I'm seeing as well now. I still
think this is worth improving, as those 5ms can add up on larger forms.
Tom Schneider wrote:
Well, I guess I was feeling more ambitious than I thought.
I wrote a simple junit test (below) that tests the 2 techniques for
retrieving I18N text. My numbers for 100 iterations were:
Using OGNL expression: 476 ms
Explicitly calling getText: 0 ms
Yikes!!! There is quite a difference between the two. The OGNL
version takes 5 ms/request compared to almost nothing for the
explicit call. It looks like it would be very beneficial to
reimplement the UIBean key lookup code based on the Text
component-style of text lookup.
Agreed. I've created:
https://issues.apache.org/struts/browse/WW-1681
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
