[
https://issues.apache.org/struts/browse/STR-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_42096
]
Patrick HIggins commented on STR-3056:
--------------------------------------
I won't be able to run that under a profiler until I get back to work on
Tuesday, but I'm pretty sure that it will have poor memory characteristics.
That was one of the first things I tried a few months ago. If you trace the
call tree, you'll see that there are many messageKey() and localeKey() calls
invoked to get there. Also, if returnNull is true, I think it won't change the
behavior at all to set cacheMisses to true.
I haven't inspected it super closely so I may be missing something, but it
looks like you just added the cacheMisses property and then you store the null
or ???locale.key??? in messages if it's set, right? If that's all you've done,
I've definitely already tried this and it cut the memory usage down only
slightly.
The real problem with the existing code is all the calls to messageKey() and
localeKey() because they create new Strings on every call. A simple object like
my MessageKey will consume a very modest amount of memory, but allocating a
String is going to also require the allocation of a char array, and those will
chew up memory fast.
> 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, prof.tar.gz, PropertyMessageResources.java
>
>
> 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.
