I got to similar numbers WHEN I was in ProjectStaged.Development only. In this case we have our DebugPhaseListener running and lots of other stuff as well.
Once I benched with PS.Production, the numbers were pretty well. LieGrue, strub ----- Original Message ----- > From: Werner Punz <werner.p...@gmail.com> > To: dev@myfaces.apache.org > Cc: > Sent: Thursday, October 13, 2011 11:20 PM > Subject: Re: Web Framework Performance Comparision > > Yes from what i gather one of the issues they had in the slides was the > overall page size. The question there is more along the lines what did > they count, just the rendered code, or also the includes. > > I can help to reduce the size on the JSF.js side. We have some code > which is not directly active for JSF 2.1 and will very likely become > part of jsf 2.2 or 2.3. it can be used today already by adding config > params, Also we have some internationalization > of the internal error messages. > > This code could be externalized into an addition js file for people who > need it. I think we might save around 20Kbytes that way. > > I personally did not think that it was necessary due to the fact that > the js files usually are gzipped while still bigger than mojarra we > after gzipping the file talk about sizes of 10-30k etc... > > In the end externalizing that code would have caused more burden on the > users than it would have helped. But given that mojarra just implements > the raw api and nothing else and does not take some corner conditions > into consideration and has no browser optimizations they are > significantly smaller in their jsf.js file and if our size is a problem > we can reduce it. > > > > > Werner > > > Am 10/13/11 11:07 PM, schrieb Leonardo Uribe: >> Hi >> >> I believe probably we already did that. The biggest bottleneck we had >> was that renderers did many calls to map.get(). Mojarra had an >> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I >> suppose with the latest code we have better numbers. >> >> regards, >> >> Leonardo Uribe >> >> 2011/10/13 Werner Punz<werner.p...@gmail.com>: >>> I would be interested as well, especially regarding their test setup, > we >>> basically doubled for instance our ajax performance between 2.0.4 and > the >>> current state of affairs. >>> >>> So it might be interesting to see what testsetup they were using. >>> From a pure memory point of view we of course have a higher load on > the >>> browser because our ajax implementation deals with things mojarra does > not >>> and also has an oo layer underneath. But I added browser specific >>> optimisations so on modern browsers we should be slightly faster than >>> mojarra in raw ajax processing (at least my personal tests resembled > that >>> when I did the profiling), while mojarra is sligtly ahead on Firefox > 3.5 and >>> IE6 and 7. >>> >>> Just giving the numbers unfortunately does not help to see where their >>> bottleneck was they discovered. >>> >>> >>> >>> Werner >>> >>> >>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz: >>>> >>>> Gang - >>>> >>>> I recently got wind of the following web framework performance talk >>>> that was presented at JavaOne: >>>> >>>> >>>> > https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf >>>> >>>> I did not attend, but based on the slides it looks like the > presenters >>>> did an very thorough/systematic job of evaluating >>>> performance/scalability for a handful of web frameworks, including >>>> JSF. (I also have to say that they slides are simply beautiful - >>>> wow!) >>>> >>>> I wanted to call attention to this talk because I am concerned > about >>>> one aspect of the results. Looking at slide #73, it seems that the >>>> presenters are seeing significant overhead in the MyFaces test runs >>>> (ie. vs. equivalent runs in Mojarra). I don't have any details > other >>>> than the $ numbers included in the slides, but seems quite possible >>>> that there is some low-hanging fruit waiting to be picked (or >>>> optimized). >>>> >>>> Is anyone acquainted with the presenters? Perhaps it would be >>>> worthwhile to contact them to see whether it would be possible to > take >>>> a closer look at the test case? >>>> >>>> Andy >>>> >>> >>> >>> >> >
