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
I'm going to be looking into optimizing the performance of the
ValueStack and because of the recent conversations regarding OGNL and
other options, I anticipate that others may have some ideas.
I've ripped off the custom stack that Bob posted to the list a couple of
a weeks ago, and have
Well, I hope I'm wrong, and have only done some initial tests so far,
but it seems to me that there are two major issues causing our
slugishness. The first seems to be OGNL and the second seems to be
freemarker templates.
By simply replacing the default value stack with the version Bob
This might be applicable: http://crazybob.org/2007/01/fast-reflection.html
Don
On 1/26/07, David H. DeWolf [EMAIL PROTECTED] wrote:
Well, I hope I'm wrong, and have only done some initial tests so far,
but it seems to me that there are two major issues causing our
slugishness. The first
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning (particularly the
freemarker entries)
By just adding the freemarker.properties and copying all the templates to
the webapp directory we were able to resolve all of our
Tom Schneider wrote:
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning (particularly
the
freemarker entries)
By just adding the freemarker.properties and copying all the templates to
the webapp directory we were able to
David H. DeWolf wrote:
Tom Schneider wrote:
David,
See https://issues.apache.org/struts/browse/WW-1661
and
http://wiki.opensymphony.com/display/WW/Performance+Tuning
(particularly the
freemarker entries)
By just adding the freemarker.properties and copying all the
templates to
the webapp
On 1/26/07, David H. DeWolf [EMAIL PROTECTED] wrote:
pages. The real kicker is when I remove the method invocations
(%{getText('')}) - this results in a 1100-1200ms/request gain (an
average of about 100ms per method invocation) and drops my total request
time to well under a second.
The
From UIBean.java:
if (this.key != null) {
if(this.name == null) {
this.name = key;
}
if(this.label == null) {
this.label = %{getText('+ key +')};
}
}
Looks like it's doing exactly the same thing. :(
Even
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
Tom Schneider wrote:
The other thing to check is to make sure devmode is off. With devmode
on, the resource bundles will be reloaded quite offend vs. not being
reload at all with devmode off. That could definitely be a culprit if
the getText calls are taking so long.
Apparently
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
12 matches
Mail list logo
