[
https://issues.apache.org/jira/browse/TAP5-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325871#comment-14325871
]
Michael Mikhulya edited comment on TAP5-2447 at 2/18/15 2:01 PM:
-----------------------------------------------------------------
I do totally agree with your feelings, init part is some kind of hack. I just
wanted to check idea without rewriting initialization part. Moreover I don't
have enough knowledge to rewrite it.
About percentage. I can't answer with 100% confident because I did this
optimization much time ago. As I found from notes it makes page rendering about
3-4% faster in my case (the best result in comparison to other optimizations
which I didn't made public yet). But probably result highly depends on number
of conduit states in components.
[~jkemnade], can you please look carefully whether there are issues with
concurrency in my patch.
By the way there is low hanging fruit related to concurrency:
{code:title=InternalComponentResourcesImpl.java}
private Map<String, Object> getRenderVariables(boolean create)
{
try
{
acquireReadLock();
if (renderVariables == null)
{
if (!create)
{
return null;
}
{code}
I looked where LockSupport is more frequently called.
And this method is the hottest one.
Whenever {{create}} is {{false}} there is no need in {{acquireReadLock}}.
I didn't checked this idea yet, but have it in TODO list.
was (Author: mihasik):
I do totally agree with your feelings, init part is some kind of hack. I just
wanted to check idea without rewriting initialization part. Moreover I don't
have enough knowledge to rewrite it.
About percentage. I can't answer with 100% confident because I did this
optimization much time ago. As I found from notes it makes page rendering about
3-4% faster in my case (the best result in comparison to other optimizations
which I didn't made public yet). But probably result highly depends on number
of conduit states in components.
[~jkemnade], can you please look carefully whether there are issues with
concurrency in my patch.
By the way there is low hanging fruit related to concurrency:
{code:title=InternalComponentResourcesImpl.java}
private Map<String, Object> getRenderVariables(boolean create)
{
try
{
acquireReadLock();
if (renderVariables == null)
{
if (!create)
{
return null;
}
{code}
I looked where LockSupport is more frequently called.
And this method is the hottest one.
Whenever {create} is {false} there is no need in {acquireReadLock}.
I didn't checked this idea yet, but have it in TODO list.
> Reset conduit states with only one access to PerthreadMap
> ---------------------------------------------------------
>
> Key: TAP5-2447
> URL: https://issues.apache.org/jira/browse/TAP5-2447
> Project: Tapestry 5
> Issue Type: Sub-task
> Components: tapestry-core
> Reporter: Michael Mikhulya
> Labels: patch, performance
> Attachments:
> 0001-Reset-conduit-states-with-only-one-access-to-Perthre.patch
>
>
> In this patch conduit states are reimplemented in the way similar to
> renderVariables. As result of it postRenderCleanup doesn't clean each conduit
> state separately.
> This patch provides about 2ms saving per page rendering on real application.
> So it is really valuable to at least review it.
> Seems like it not only because of reducing access to PerthreadMap, but also
> because decreasing number of read locks because of NamedSet usage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
