You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org> on 2008/01/19 00:59:34 UTC
[jira] Created: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
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
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.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561404#action_12561404 ]
Matthias Weßendorf commented on TRINIDAD-906:
---------------------------------------------
commit to this ticket isn't listed on "Subversion Commits" tab.
so here it goes:
http://svn.apache.org/viewvc?view=rev&revision=613322
(the one for the 1.2._x trunk)
> 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"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561478#action_12561478 ]
Scott O'Bryan commented on TRINIDAD-906:
----------------------------------------
Then yeah, I think you implemented this correctly.
> 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.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560627#action_12560627 ]
Gabrielle Crawford commented on TRINIDAD-906:
---------------------------------------------
Completed: At revision: 613331 for trunk 1.0
> 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"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561439#action_12561439 ]
Gabrielle Crawford commented on TRINIDAD-906:
---------------------------------------------
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.
> 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.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561462#action_12561462 ]
Gabrielle Crawford commented on TRINIDAD-906:
---------------------------------------------
Thanks for the comment. Yes, there is no state stored on the thread, we are not caching any part of the id, we use a stringBuilder to create the id, and then immediately call toString, so this change is just to avoid allocating new StringBuilder instances.
> 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.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561256#action_12561256 ]
Martin Marinschek commented on TRINIDAD-906:
--------------------------------------------
Hi Gabrielle,
I'm just wondering - would it be better to store the String-Builder as a request-Attribute? As you get passed a FacesContext into getClientId() anyways, you might save some CPU-cycles which are necessary to retrieve the the thread-local variable?
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"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Issue Comment Edited: (TRINIDAD-906) optimize getClientId -
use per thread shared StringBuilder
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560618#action_12560618 ]
gabrielle edited comment on TRINIDAD-906 at 1/18/08 4:46 PM:
----------------------------------------------------------------------
Completed: At revision: 613322 for trunk 1.2
was (Author: gabrielle):
Completed: At revision: 613322
> 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"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ 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"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561498#action_12561498 ]
Scott O'Bryan commented on TRINIDAD-906:
----------------------------------------
Yeah Martin, I think you're correct on that. I know that 1.4 had some major performance enhancements especially on things like threads.
Scott
> 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.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561491#action_12561491 ]
Martin Marinschek commented on TRINIDAD-906:
--------------------------------------------
Up to JDK<1.4 getting the current thread seemed to be expensive - I didn't find any numbers for 1.4, 1.5 or 1.6, just the general statement that in 1.4, this is better. Thanks for the clarification, Scott!
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
> 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.
[jira] Resolved: (TRINIDAD-906) optimize getClientId - use per
thread shared StringBuilder
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabrielle Crawford resolved TRINIDAD-906.
-----------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.6-core
Completed: At revision: 613322
> 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.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.