[ 
https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561455#action_12561455
 ] 

Scott O'Bryan commented on TRINIDAD-906:
----------------------------------------

ThreadLocal is indeed much faster.  Getting a reference to the current thread 
object is not too bad.  

You have to be careful in using ThreadLocal though.  If the object your caching 
needs to be accessible from both the Lifecycle.render AND the 
Lifecycle.execute, these are NOT guaranteed to happen in the same thread in a 
portal environment.  If this enhancement is mearly for the purposes of caching 
the StringBuilder object to prevent us from having to create a new object, this 
is probably fine because we might just create two objects instead of one.  Just 
make sure this doesn't store any needed state.  If it does, you're best off 
using a request attribute even though it's slower.

> 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
>            Assignee: 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"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to