Performance Profiler output for rendering dataTable with Sea

[mgrouch]

Please, take a look at screenshot here

http://jira.jboss.com/jira/browse/RF-726
http://jira.jboss.com/jira/secure/attachment/12315717/12315717_JBossProfile.GIF


There are 2 JBoss function which take significant time

These 2 functions took a lots of calls and a lot of time

24% for org.jboss.seam.ui.HtmlLink.encodeBegin(FacesContext)
32% for org.jboss.seam.intercept.JavaBeanInterceptor.intercept(Object, Method, Object[], MethodProxy)

Table (rich:dataTable) had 22 columns and 100 rows of data.

Why org.jboss.seam.ui.HtmlLink.encodeBegin would take so much CPU?
Same applies to org.jboss.seam.intercept.JavaBeanInterceptor.intercept?

Is there any way these methods could run faster?

Thanks
--MG

[mgrouch]

If I expand profile beyond org.jboss.seam

it shows that (AnotherRun.jpg)

javax.faces.component.UIData.getValue()

takes 49% of time (with 1% own time) and is called 4,201 times

It seems it is being called to excessively. Is there a way to avoid so many calls to it during rendering?

Thanks

[ellenzhao]

I find the rendering of my Seam app very slow too, not sure who's fault (RichFaces? Facelets? Seam? My code? ). Especially slow is the evaluation of the "rendered= ...." conditions. RHS of each "rendered=..." expression is evaluated separately at every page load. There should be stuff like batch evaluation, or Rete-based evaluation algorithm to boost the rendering performance.

[mgrouch]

One more surprising finding with rendering table.
I tried to compare rendering time (RENDER phase and overall response time)
by rendering same table with regular h:dataTable tag
and using facelets ui:repeat

like this

<table>
<tr jsfc="ui:repeat" value="#{recordList.resultList}" var="record" class="row">
<td>#{record.id}</td>
...
</tr>
</table>

facelets render it 3 times!!! faster on average (I did number of runs to get good stats).

(22 columns, 100 rows)

[mgrouch]

I find the rendering of my Seam app very slow too, not sure who's fault (RichFaces? Facelets? Seam? My code? ).

I think it is JSF implementation itself. Even if I use basic JSF tags it is still slow. Third-party component libraries ad their own performance problems,
but it seems even pure JSF app which uses only basic tags runs slow.
(Even if I use server side state saving).

Another problem that if a user in frustration clicks multiple times on a link which leads to slow JSF page it practically kills app server for quite some time
making it essentially easy denial-of-service attack.

Thanks

[mgrouch]

One more observation

During rendering table with h:dataTable it accesses number of other beans

2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.contexts.Contexts] found in event context: record^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.contexts.Contexts] found in event context: recordList^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.intercept.RootInterceptor] intercepted: recordList.getResultList^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.preSetVariable.recordList^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] instantiating Seam component: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] initializing new instance of: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.Component] done initializing: org.jboss.seam.core.events^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.core.Events] Processing event:org.jboss.seam.postSetVariable.recordList^M
2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.util.Naming] JNDI InitialContext properties:{java.naming.factory.initial=org.jnp.interfaces.NamingContextFacto
ry, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}^M

when I render same table using UI:repeat
It does less work achieving same result.

Only these lines repeat (no access to other conmonents)

2007-08-26 22:18:08,093 DEBUG [org.jboss.seam.contexts.Contexts] found in event context: record^M

[mgrouch]

More interesting results

with the following settings in web.xml

<context-param>
 <param-name>facelets.BUFFER_SIZE</param-name>
 <param-value>500000</param-value>
 </context-param>
 <context-param>
 <param-name>com.sun.faces.responseBufferSize</param-name>
 <param-value>500000</param-value>
 </context-param>

performance of data table rendering improves.

Rendering using h:dataTable
now works a bit faster than
rendering same table with ui:repeat.

So it seems reallocations in response buffer were responsible
for slowing down RENDER phase.