Hi Some days ago Thomas Andraschko told on users list that he already have a variant of this for MyFaces. Look the mail with subject:
"Weird PlexusContainer object in ViewRoot" I think it is a good idea to put that code in myfaces commons or as an extension (extensions/stateless-jsf ?). Since the license of the code is ASL, it is possible to host it here. To make this possible I think we should vote about create a module. @Thomas: could you create an issue on myfaces issue tracker: https://issues.apache.org/jira/browse/MYFACES and attach the code you are working on, so the PMC can vote if it is worth to create the subproject? About performance of MyFaces code vs Mojarra: I think with the latest changes MyFaces code looks very good. Yes, there is a lot of room from improvement. I think it is possible to do things like trim spaces in facelets compiler, remove <!-- --> on the scripts (it is there because very early versions of MyFaces do that), or optimize js rendering using some myfaces specific code instead call javax.faces js api. But note recent optimization in myfaces renderers has been improved its base speed. If you exclude the javascript rendering part, MyFaces renderers looks good. I think we should let those optimizations for 2.2. The only thing left to start working on that branch is reorganize shared modules (split shared in two, cleanup and maybe create myfaces-impl-api submodule to hold stuff like spi interfaces and other myfaces-impl api to be used for integration points). Right now, MyFaces 2.1.6 uses a lot less memory, and recent improvements into its PSS algorithm has reduced the required state size for views, making it very efficient. regards, Leonardo Uribe 2012/2/9 Werner Punz <[email protected]>: > Hia just a general discussion, regarding performance. One of the big > performance impacts is statefulness, now there has been a project > > http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ > > This however is only for Mojarra, shouldnt we target something similar, one > day or the other it will be part of the spec, so targetting this early might > give the mojarra guys a push for going there also. > > If you look at the numbers you can see there is a lot to gain by being able > to render pages stateless one way or the other. > I personally think in the typical extranet site, most pages are able to go > stateless and about 5-10% should be stateful, that way we could cover both. > > Another performance issue I still have gripes with is the rendered code. > For a small page we on the average still have way more code rendered than > Mojarra, in some cases up to 40%. Which is a lot. > > While we already did some work regarding our onclick event javascript calls, > there is still lots of room for optimization in our code. > For instance we render <!-- --> with all linebreaks and spaces between link > and script tags intact. > > Mojarra basically strips all unneeded stuff and renders only the script and > link tags without any blanks. > > > > > Werner >
