Great work, Werner. It's good to know how things stack up performance-wise, and which areas can be improved. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3
Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17 On Thu, Jul 8, 2010 at 11:06 AM, Werner Punz <[email protected]> wrote: > Hello everyone since I was working on it anyway I did some performance > investigations of one of my testcases (a dialog box utilizing jquery > and doing some refreshes within and outside of it. > > Besides that I discovered that we were far behind mojarra peformancewise (I > recently made performance mesurements on the body replacement part where the > difference was better on our side, but a load has changed there as well), > which I now have mostly fixed for that case I discovered some interesting > stuff. > > First I raised an issue for it under > > https://issues.apache.org/jira/browse/MYFACES-2797 > > By resolving it we gained about 30-40% 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 failed the testcase on opera and chrome > (probably any webkit based browser) > > > Note this is for a small html to medium sized html replacement case. We > probably gain speed on bigger replacements if the server delivers on equal > ground, due to browser optimizations, we have on dom level. > > Anyway: > > There are a multitude of performance problems, the ones on my side > hopefully are mostly fixed. I now can live with the performance difference > given that we do way much more and probably have it easier with maintenance > in the future. > > The biggest issue was that Mojarras jsf.js was almost twice as fast as > ours, I pushed the difference down to some 10-15%. The biggest culprit was > that Mojarras code entirely failed on Webkit and Opera for the testcase, > while ours worked. > > The difference now can probably be attributed to following things after the > performance update. We are more modularized and have an oo layer which also > costs some performance (not too much but nevertheless), we have a load of > browser fixes and solve things probably differently to be absolutely safe in > seldom corner cases, can deal with control detachments, cross form submits > submits against controls with embedded forms, pps etc.. > > Mojarra obviously does not have all this, (otherwise it would not have > failed on chrome and opera) which attributes to another load of indirections > and code. > > Nevertheless after spending the day on performance tweaking we are on our > side now at an acceptable level for this case (which is small to medium > sized ppr updates) > > The bigger performance difference now is caused by the server which > attributes to 95% of the refresh. > The biggest issue I could discover from the client, is our rendering of way > too much inline scripts. > > While Mojarra renders for a form update or generally a form only the raw > html code and some helper functions included separately, we inline the > oamsubmit functions constantly blowing our page up. While this is not bad > for normal cases (still costs rendering performance), the oam function adds > on my side another 10-15% performance loss on dom replacement level if a > target is refreshed which causes them to be rendered. > > Another performance shortcut Mojarra seems to take is on ViewScoped beans, > we restore the bean constantly at every ppr request which does something on > a viewscoped bean, mojarra seems to take a shortcut here. You can see that > by using a ViewScoped bean in myfaces the deserialisation in the bean is > called at every ajax request, in mojarra it is not. > > I just wanted to post this since people work on performance issues on the > server side as well. > > Werner > > > > > >
