[ https://issues.apache.org/jira/browse/TAP5-2694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nikkie Folts updated TAP5-2694: ------------------------------- Description: 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} 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? was: 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 !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} 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? > Tapestry PlasticClassPool & PropBinding 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 > 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 > > > 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} > 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)