[
https://issues.apache.org/struts/browse/STR-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick HIggins updated STR-3056:
---------------------------------
Attachment: message_resources_cache_null.patch2
struts-patches.html
I have attached an updated version of my MessageKey + cacheNull patch which
uses Paul's idea of storing the ???message.key??? return values in the messages
HashMap if returnNull is false. This makes the patch behave well for all
combinations of returnNull and cacheNull.
I have also attached a spreadsheet comparing the performance of unpatched
Struts, my patch, and Paul's patch. Paul's patch does not have any significant
change in behavior over unpatched Struts. My patch uses only 2% of the memory
and between 6% and 20% of the time of the unpatched version.
Please review my patch more closely and let me know if there are any specific
objections to the techniques I'm using. My testing indicates that this could
speed things up for our usage tremendously.
Also, I may create a separate patch intended to go on top of this patch if it
is accepted. I've found that the isTraceEnabled() at the top of loadLocale() is
actually a bit of a hotspot after my patch is applied.
> PropertyMessageResources.getMessage() does not cache failed lookups
> -------------------------------------------------------------------
>
> Key: STR-3056
> URL: https://issues.apache.org/struts/browse/STR-3056
> Project: Struts 1
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1.0, 1.3.8
> Environment: Applies to all environments
> Reporter: Patrick HIggins
> Fix For: 1.4.0
>
> Attachments: cache_null.patch, message_resources.patch,
> message_resources_cache_null.patch, message_resources_cache_null.patch2,
> prof.tar.gz, PropertyMessageResources.java, struts-patches.html
>
>
> We have an application that allocates lots of garbage (sometimes over 100MB)
> when rendering a single page. After using Netbeans profiler with it, I've
> found that a lot of that garbage is created by MessageResources.messageKey().
> It appears that we are calling bean:write (WriteTag) thousands of times, and
> it looks up the message for "org.apache.struts.taglib.bean.format.int" to try
> to find a default format for integers. We have not defined this property in
> our ApplicationResources, so it ends up returning the value
> "???en_US.org.apache.struts.taglib.bean.format.int???" after searching
> exhaustively for it. It does not cache this value. Then, when we call it the
> next 8,000 times, it performs the same exhaustive search over and over
> because it's not caching the negative response.
> I propose that negative responses get cached, too. That would save a lot of
> time and memory so that WriteTag can just go ahead and call toString() on the
> instance of java.lang.Integer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
