myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject MyFaces performance investigation from a client point of view
Date Thu, 08 Jul 2010 15:06:23 GMT
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






Mime
View raw message