You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Stevan Malesevic (JIRA)" <de...@myfaces.apache.org> on 2010/05/14 00:11:42 UTC

[jira] Created: (TRINIDAD-1809) CPU impact for repeated calls to isRenderer on UIXComponentBase

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.


[jira] Commented: (TRINIDAD-1809) CPU impact for repeated calls to isRenderer on UIXComponentBase

Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
    [ 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.