-
1. Re: JBoss EL performance vs Sun EL
fhh Sep 15, 2007 4:28 AM (in response to mgrouch)I very much doubt that. The reason why rendering large tables is slow in JSF is the building of the component tree.
Regards
Felix -
2. Re: JBoss EL performance vs Sun EL
mail.micke Sep 15, 2007 5:47 AM (in response to mgrouch)Hi
I have also noticed performance issues when I use EL a lot with table rendering. Don't think it is specific to tables, just a lot of EL resolving going on. Not blaming EL, I am probably using it in ways it shouldn't be.
In short when I added rendered property on each rich:column on a table, 6-8 seconds are spent in the render response lifecycle (when rendering about 100 rows). Compared milliseconds, when I remove the EL and just render all columns.
There is a thread about it here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118257
- Mike -
3. Re: JBoss EL performance vs Sun EL
norman.richards Sep 15, 2007 1:04 PM (in response to mgrouch)I don't know that anyone has performance tested jboss-el.
-
4. Re: JBoss EL performance vs Sun EL
mgrouch Sep 15, 2007 4:41 PM (in response to mgrouch)
I very much doubt that. The reason why rendering large tables is slow in JSF is the building of the component tree.
No it is EL. I can see it in profiler.
JSF doesn't have ability to define a variable so you have to
recalculate EL expressions over and over (and that is using reflection!).
JSF doesn't have if/else concept it only has 'rendered'
so where you would normally had 'switch' statement evaluated once
JSF has to evaluate 'rendered' again and again (with reflection!).
I wonder if any thought on performance implications was given during JSF design... -
5. Re: JBoss EL performance vs Sun EL
mgrouch Sep 15, 2007 5:21 PM (in response to mgrouch)Here is some more interesting info on EL performance.
Looks like Eclipse also had problems and they managed to speed it up significantly.
http://dev.eclipse.org/mhonarc/lists/wtp-jsf-dev/msg00271.htmlWTP 2.0 RC0 is targeted to release with a badly needed improvement to JSF EL validation performance.
Based on performance benchmarking you should see worst case performance roughly twice as fast and average case as much as 300 times faster when validating EL expressions involving #{bean.property} type expressions. I am also seeing a speed improvement of about 3 times when running my larger EL validation test suites.
Special thanks to Matthias Fuessel for providing us with a targeted caching mechanism to make this performance improvement possible.
To see all the details of the issue see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=163890
Can something like this be done to JBoss EL?
Thanks -
6. Re: JBoss EL performance vs Sun EL
pmuir Sep 15, 2007 6:46 PM (in response to mgrouch)I'm not sure that thread really relates to EL but to tooling for EL - it is discussing caching the results of scanning backing beans for valid EL - of course EL doesn't need to scan but resolve. Or am I missing some insight you've had?
-
7. Re: JBoss EL performance vs Sun EL
mgrouch Sep 15, 2007 8:34 PM (in response to mgrouch)Here is a piece of code to show what I'm trying to say.
In JSF EL same getters are called using reflections over and over again quite usually. So few reflection API calls could be spared and called once only.import java.lang.reflect.Method; public class ReflectionTest { private String myProp = "VALUE"; Class[] argTypes = new Class[] { }; Object[] arg = new Object[0]; Method getterMethod; public Object getBeanProperty(Object bean, String propName) throws Exception { Class clazz = bean.getClass(); String getterName = "get" + Character.toUpperCase(propName.charAt(0)) + propName.substring(1); getterMethod = clazz.getDeclaredMethod(getterName, argTypes); Object obj = getterMethod.invoke(bean, arg); return obj; } public Object getBeanPropertyViaCachedMethod(Object bean, String propName) throws Exception { Object obj = getterMethod.invoke(bean, arg); return obj; } public String getMyProp() { return myProp; } public static void main(String... args) throws Exception { ReflectionTest testBean = new ReflectionTest(); final int ITERATIONS = 1000000; long start = System.currentTimeMillis(); for (int i = 0; i < ITERATIONS; i++) { String str = (String) testBean.getBeanProperty(testBean, "myProp"); //System.out.println(str); } long finish = System.currentTimeMillis(); System.out.println("Run1 time=" + (finish-start) + "ms"); start = System.currentTimeMillis(); for (int i = 0; i < ITERATIONS; i++) { String str = (String) testBean.getBeanPropertyViaCachedMethod(testBean, "myProp"); //System.out.println(str); } finish = System.currentTimeMillis(); System.out.println("Run2 time=" + (finish-start) + "ms"); } }
Outputs (on my PC)
Run1 time=2906ms
Run2 time=140ms
Now more or less realistic example:
Render table 1000 rows 10 columns each cell has a dropdown of 100 elements
That's a million reflection calls -
8. Re: JBoss EL performance vs Sun EL
mgrouch Sep 15, 2007 9:16 PM (in response to mgrouch)Now here is an illustration how ridiculously inefficient JSF design is.
It forces developer to write the most inefficient code
Example:
based on type value stored in columnBean.type you need to render
several different HTML controls
So you would have to repeat<s:fragment rendered="#{columnBean.type == 'type1'"> fragment1 </s:fragment> and so on.
In regular programming language there would be a 'switch' statement
and since conditions are mutually exclusive after one condition is met
there is no need to evaluate others.
1) In JSF for N mutually exclusive 'rendered' conditions they will
ALWAYS be evaluated N times!!!
2) Even worse there is no syntax to assign columnBean.type to a variable
so it will be EVALUATED EACH TIME!!!
3) Even worse it will be evaluated using REFLECTION!!!
4) JSF will give you temptation to write condition as STRING comparison
(Though this is avoidable, but most people write it exactly that way cause
declaring a constant is not supported)
Please, correct me if I'm wrong about something. (Might be things are not that bad) -
9. Re: JBoss EL performance vs Sun EL
halivingston Sep 16, 2007 4:49 PM (in response to mgrouch)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? -
10. Re: JBoss EL performance vs Sun EL
pmuir Sep 16, 2007 5:48 PM (in response to mgrouch)No, it shouldn't take many seconds. JSF does have an overhead, however I'm not an expert on this and so can't provide a definitive answer. Some people have done extensive performance work on JSF/Facelets (Adam Winer springs to mind) - you should be able to find it by googling.
N.B. Eelco has basic Seam integration in Wicket (not sure what version of Wicket, or perhaps CVS) -
11. Re: JBoss EL performance vs Sun EL
mgrouch Sep 16, 2007 9:44 PM (in response to mgrouch)So, you're saying a Data Grid listing with 100 rows is going to take like many seconds to render?
Yes depending on how many controls you are putting inside table,
and how man times you invoke EL I've seen ~3-5 sec rendering phase times
even with 100 rows (on 2GHz PC)
Most of the invocations from EL are getters so might
you could have something like invokeGetter() method which will
skip much of logic which is designed to support generic invocations in
ReflectionUtil.java
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss-el/trunk/src/org/jboss/el/util/ReflectionUtil.java
Was there any stress testing and profiling done on JBoss EL previously?
Thanks -
12. Re: JBoss EL performance vs Sun EL
lowecg2004 Sep 17, 2007 10:14 AM (in response to mgrouch)Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?
In addition to all the EL parsing, reflection, etc. the EL calls will probably be subject to several layers of interception. Do these show up in your timings?
I know you've run a profiler on the session and currently all fingers point to EL, but another thing to consider is that there are certain cases in IE where the browser itself is incredibly slow at rendering tabular data. I had a JSF app that rendered incredibly slowly. After profiling, I saw that the response was generated in a fraction of the time that I was witnessing. Even after saving the generated HTML to a file and opening up in IE it generated slowly. Opening the same file in Firefox was very quick. Like I said, probably not directly relevant here, just something to look out for. -
13. Re: JBoss EL performance vs Sun EL
mgrouch Sep 17, 2007 11:02 AM (in response to mgrouch)Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?
I posted some code before https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=625In addition to all the EL parsing, reflection, etc. the EL calls will probably be subject to several layers of interception. Do these show up in your timings?
I haven't really investigated impact of interseption. I my past experience
of rendering tables without Seam it was slow too.I know you've run a profiler on the session and currently all fingers point to EL, but another thing to consider is that there are certain cases in IE where the browser itself is incredibly slow at rendering tabular data.
I've seen it too, but I'm not talking here about client side.
I'm clocking renderding phase on server side. (JSF Phase listener
displays timing of all JSF phases on server side). -
14. Re: JBoss EL performance vs Sun EL
mgrouch Sep 17, 2007 2:57 PM (in response to mgrouch)Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?
One easy way to demo it: Create a large table and render dropdowns
with s:selectItems in each cell.
It can be used for stress testing EL, rendering, form submission, validation, etc.
Thanks