[
https://issues.apache.org/jira/browse/TRINIDAD-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867479#action_12867479
]
Martin Marinschek commented on TRINIDAD-1809:
---------------------------------------------
Hi Stefan,
yes, you are right - it would be safe to do this. In cs-JSF we do exactly this
- we also cache the rendered attribute from the begin of processDecodes until
the end of invoke application.
However: if you cache this in a transient attributes, you need to treat stuff
in data-tables differently. Transient attributes are not saved/restored per row
while a data-table is processed, a long standing issue we have with the spec.
best regards,
Martin
> CPU impact for repeated calls to isRenderer on UIXComponentBase
> ---------------------------------------------------------------
>
> Key: TRINIDAD-1809
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1809
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Reporter: Stevan Malesevic
>
> While using Trinidad framework we noticed that even with very complex app
> having complex bus logic we still spend some 2-3% of time doing checks on
> isRenderer() on UIXComponentBase. In general the problem is that number of
> these are EL expression on some EL expressions are not very cheap to
> evaluate. Now, the fact that there are number of duplicate checks makes the
> cost higher. The big chunk of calls comes from 3 areas
> 1. encodeBegin, encodeChild and encodeEnd all do the check
> 2. __encodeRecursive does a check and then invokes methods from 1.
> 3. CoreRenderer.encodeChild also does a check and then calls group 1.
> Generally it should be possible to mark renderer as local property at the
> begging of comp rendering and use it . This should save a 1/3 of cpu cycles
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
