[ 
https://issues.apache.org/jira/browse/TAP5-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325612#comment-14325612
 ] 

Jochen Kemnade commented on TAP5-2447:
--------------------------------------

I had a look at that patch but I haven't completely made up my mind yet. The 
change definitely makes sense to me, but I'm a bit concerned about the 
{{init(PerThreadValue conduitStates)}} part. I cannot put my finger on it but 
somehow it feels a little awkward.
{quote}
This patch provides about 2ms saving per page rendering on real application.
{quote}
What's that as a percentage? 2ms doesn't sound too much, I would have expected 
a bigger effect.

> 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)

Reply via email to