[ 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.