[mgrouch]

I've opened JIRA issue for EL performance.

http://jira.jboss.com/jira/browse/JBSEAM-1977

Looks like it can be done almost 10 times faster with cglib.
JIRA has code sample to demonstrate that.
I hope you could squeeze this into 2.0. I think this could make major
improvements in performance (especially for apps which use lots of EL)

Thanks

[mgrouch]

Has anyone had a chance to compare JBoss EL perfromance with
JUEL http://juel.sourceforge.net/?

Also in cases where type is known would it be possible to use
EL compiled into bytecode?

Like here http://sixlegs.com/blog/java/compiled-el.html

Thanks

[mnesarco]

"halivingston" wrote:
So, you're saying a Data Grid listing with 100 rows is going to take like many seconds to render?

I haven't joined the JBoss Seam bandwagon yet. I was going to, but are these performance issues going to persist? Change in JSF 2.0? etc? Or is it better to try Wicket?

If you really want to try Apache Wicket, there is an integration project with Seam 2.

The Seam-Wicket integration has been officially started at wicket-stuff (https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/ ).

See this blog: http://www.ibstaff.net/fmartinez/?p=41 to get the binary and a convenient trivial example project.

[markcollette]

Maybe there could be some APIs added for setting the scoping of caching of resolution of expressions?

I can think of some cases where #{bean.dataModel} should be evaluated once per render, or where it should be evaluated over and over. So why not have some hint? With Facelets there's the c:set tag, which does not cache the evaluation. Maybe one could be added that will.

And then, for dataTables, and other UISeries, there could be some means of them setting a hint on their row var, so that that part of the expression is only evaluated once, while in the context of each individual row.

[pmuir]

Yes, I understand the need for such a caching tag. However this is probably best added to facelets. Please raise an issue in their bug tracker and paste a link here so I can track it.

[mgrouch]

While this will help with performance it will not be enough to match JSP.

You will still have many cases where you have to evaluate expression
#{bean.prop1}
#{bean.prop2}
#{bean.prop3}
#{bean.prop4}
#{bean.prop5}
#{bean.prop6}

and so on. (Case of rendering table)

EL has to be compiled into byte code instead of reflection calls
to really perform, so it has to be made type-safe via type declarations
of variables.

Caching of evaluated expressions is only partial solution.

[gonzalad]

Hello,

I've also some serious performance problems with Jsf/Seam.

Some of these problems is due to SeamELResolver|getValue.

My sample application can stand only 3 users (no think time).
The application consumes 50% of the cpu (AIX system - don't have now the processor caractéristics).
Average response time = 0,5s - 8tx/s - average page size 55ko (html) .

Profiled a page (it's search page with 2 criteria that renders a list) with Wily Introscope.
24.3% of request duration is due to
org.jboss.seam.el.SeamELResolver|getValue
which calls Namespace.getComponentInstance in a loop.
each call to Namespace.getComponentInstance consumes between 2 ou 4 ms.
2% for my Action execution (which calls jpa).

I can send the full trace if you're interested (size=400Mo).

[mgrouch]

Yes, I understand the need for such a caching tag. However this is probably best added to facelets. Please raise an issue in their bug tracker and paste a link here so I can track it.

There is one open for Gravel

http://jira.jboss.com/jira/browse/GRAVEL-27

[mgrouch]

And there is another JIRA opened for compiled EL.
Please, vote for it.

http://jira.jboss.org/jira/browse/JBSEAM-2141

based on ideas from

http://sixlegs.com/blog/java/compiled-el.html

Thanks