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
