[
https://issues.apache.org/jira/browse/MYFACES-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2797.
----------------------------------
Resolution: Fixed
resolved we gained about 30% of raw exection performance, for a simple often
triggered update case we are about 10% slower than mojarra on the raw
javascript execution, but our code works on absolutely all desktop browsers
including ie6 while mojarra fails the testcase on opera and chrome (probably
any webkit based browser)
The bigger performance issues now are on the server
> jsf.js Performance of raw updates could need improvement compared to mojarra
> ----------------------------------------------------------------------------
>
> Key: MYFACES-2797
> URL: https://issues.apache.org/jira/browse/MYFACES-2797
> Project: MyFaces Core
> Issue Type: Improvement
> Affects Versions: 2.0.1
> Reporter: Werner Punz
> Fix For: 2.0.1-SNAPSHOT
>
>
> I ran the performance testing again against the scripts and found following
> out, for ie we use innerHTML with some fixes
> for the rest contextual ranges, this works, but contextual range creation is
> way slower than using innerHTML, neither is W3C standard, but at least
> innerHTML is supported over all browsers (with some bugs in older ie
> versions where it stems from), but innerHTML will be part of the HTML5 spec,
> since I solved all ie6 related innerhtml problems for our usecase I guess it
> is save to move over to innerHTML, we are talking about a differentce of 42
> miliseconds on firefox 3.6 between the two methods.
> Mojarra still is faster (but fails to run my performance test on chrome,
> while our scripts work),
> this is partially caused by MyFaces constantly sending oamSubmit for a form
> refresh (we should move that code finally out into an external resource), but
> also partially on the javascript side, one reason for the performance
> bottleneck was the usage
> of contextualRanges which are half as fast as innerHTML.
> Another issue is our oo layer, eval is calls way too often globalEval,
> introducing a namespace index should resolve this.
> On dom level the heaviest operation is the replaceElements probably by some
> inlining for the 95% simple cases we can resolve that one to mojarra levels.
> Last but not least our exectScript also can be performance improved by simply
> concatenating all scripts and then doing a single eval.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
