Hi Martin,
Thanks for the feedback. I have to say, I'm not a perf expert, I
suggested using the request and it was the perf guy here who suggested
ThreadLocal instead.... if anyone has perf concerns about this please
let me know.
Thanks,
Gab
Martin Marinschek (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561265#action_12561265 ]
Martin Marinschek commented on TRINIDAD-906:
--------------------------------------------
Ok, I've read a little more - ThreadLocal doesn't need a synchronized access
anymore, but obviously getting the current thread still needs some performance.
Well, your performance guys will be able to tell you ;)
regards,
Martin
optimize getClientId - use per thread shared StringBuilder
----------------------------------------------------------
Key: TRINIDAD-906
URL: https://issues.apache.org/jira/browse/TRINIDAD-906
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.5-core
Reporter: Gabrielle Crawford
Priority: Minor
Fix For: 1.0.6-core, 1.2.6-core
In getClientId/getContainerClientId we create a new stringBuilder.
However when creating a client id we only use one stringBuilder at a time, so have a single instance of a StringBuilder saved on thread local.
Have a utility to get this instance, and any time a user gets the instance, set the length of the stringBuilder to 0. This will completely break if a user tries to call it for 2 stringbuilders, so doc this well.
Preliminary testing by a performance person here at Oracle found "the saving is
~300KB out of 5850KB for the request. This is about 5% total request memory. As expected
profile shows that most of the memory saving comes from not creating huge number of
string builders"
