[jira] [Closed] (TAP5-2694) Tapestry PlasticClassPool & PropBinding & LiteralStringProvider make thousands of duplicate strings

["Thiago Henrique De Paula Figueiredo (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thiago Henrique De Paula Figueiredo closed TAP5-2694.
-----------------------------------------------------
    Fix Version/s: 5.8.0
       Resolution: Fixed

Hello, [~billapepper]!

Thank you very much for these findings!

I implemented your suggestions, except the PropBinding toString() one, since it's built using the component complete id, so it doesn't have that many repeated strings. I've also added interning of returnType, methodName and genericSignature in MethodDescription, since these tend to be repeated a lot.





> Tapestry PlasticClassPool & PropBinding & LiteralStringProvider make thousands of duplicate strings
> ---------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-2694
>                 URL: https://issues.apache.org/jira/browse/TAP5-2694
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: plastic
>    Affects Versions: 5.7.3
>            Reporter: Nikkie Folts
>            Assignee: Thiago Henrique De Paula Figueiredo
>            Priority: Major
>             Fix For: 5.8.0
>
>         Attachments: Screen Shot 2021-09-29 at 4.02.26 PM.png, Screen Shot 2021-09-29 at 4.03.04 PM.png, Screen Shot 2021-09-29 at 5.23.53 PM.png, Screen Shot 2021-09-30 at 4.58.19 PM.png, Screen Shot 2021-10-04 at 2.07.35 PM.png
>
>
> I have completed a memory profile of our Tapestry application, and found that the PlasticClassPool & PropBinding have lots of duplicate Strings in memory. 
> h2. PropBinding
> Seems that both the `toString` and `expression` constructor parameters of PropBinding should be interned in the constructor.
>  !Screen Shot 2021-09-30 at 4.58.19 PM.png! 
> h2. PlasticClassPool
> After some investigation, it seems that the `InheritanceData#getValue()` method is the likely culprit.
> h4. Example Strings:
> "toString:()"
> "get:(Ljava/lang/Object;)"
> "getPropertyName:()"
> h4. The current method:
> {code:java}
>     /**
>      * Combines a method name and its desc (which describes parameter types and return value) to form
>      * a value, which is how methods are tracked.
>      */
>     private static String toValue(String name, String desc)
>     {
>         // TAP5-2268: ignore return-type to avoid methods with the same number (and type) of parameters but different
>         //            return-types which is illegal in Java.
>         // desc is something like "(I)Ljava/lang/String;", which means: takes an int, returns a String. We strip
>         // everything after the parameter list.
>         int endOfParameterSpecIdx = desc.indexOf(')');
>         return name + ":" + desc.substring(0, endOfParameterSpecIdx+1);
>     }
> {code}
> h4. The change is simple one-liner to the return statement:
> {code}
> return (name + ":" + desc.substring(0, endOfParameterSpecIdx+1)).intern();
> {code}
> h2. PageElementFactoryImpl$LiteralStringProvider
> The constructor for LiteralStringProvider should intern the string.
> h2. Also, Duplicate InheritanceData
> The profile also showed that there are lots of "duplicate" InheritanceData objects... the interning will help with their size, but why have so many duplicate?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)