Since Andy Schwarz posted following link in the MyFaces mailing list, with especially page #73 showing MyFaces in a relatively bad light compared to Mojarra without any further data given, I have become curious where we really stand. I could not believe the diagram shown here, because it did not resemble my personal day to day experience (the entire numbers shown also the html size etc..) seemed like a rather old build of MyFaces probably around 2.0.2-2.0.4.
My personal assumption was that the implementation used was a rather old MyFaces version.
We have made major performance improvements between 2.0.4 and the current snapshot version which is 2.1.4-SNAPSHOT and 2.0.10-SNAPSHOT and Mojarra on version 2.1.2.
So here is my test setup. I basically took an existing integration test suite I have had developed the last month and added client side timestamp performance measurements.
By comparing the succeeded tests on both platforms under identical conditions you can get a good overview over the client side and server side performance numbers of both implementations.
Both tests were run in Production mode which resembles a live system under the same setup, with all optimisations on, a Maven Jetty configuration was used as servlet runner. Test browser was the latest Mozilla Firefox, but on other browsers the results are pretty similar.
So here are the numbers:
|1. JSF Protocol Tests||239||207|
|2. Full Body Replacement||42||35|
|3. Multi form situation||4134||4426|
|4. Testing for decorated api calls||24||34|
|5. Double Eval Detection||2047||2060|
|6. Table Test, replacement of table elements||7289||9229|
|6. Partial Page Rendering Nav Case||2168||2308|
|7. Event Lifecycle test||130||131|
The rest of the tests are slightly ahead of Mojarra, so the server seems to be under the same test setup conditions slightly ahead of Mojarra, here also in a 10-15% range.
On the page rendering side however the generated code from Mojarra seemed to be about 5-10% smaller than MyFaces´s code. The difference used to be much bigger but some improvements have been made in this area as well on our side.
To sum this up, performancewise you definitely cannot go wrong with any of both implementations.
And none of both implementations has a significant performance advantage over the other.
But back to the original article.
I really would like which version the authors used to come to their conclusion on page #73 and how it would look like with the latest codebase.