Oops, I guess I should put this comment in the issue. :-)
Gabrielle Crawford wrote:
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"
