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 lon
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
retri
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 there
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
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. :(
Ev
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 ta
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
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,
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 freemar
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 see
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 poste
Hey David,
Are you finding the existing ValueStack to be impacting performance? I
recently wrapped up a week of tweaking our webwork app and I did some
testing of the OGNL expressions and that was definitely not where our
performance issues were. If OGNL is an issue for you, I'd be curious to
kn
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 reali
13 matches
Mail list logo
