Re: OGNL performance detrimental to Struts 2
When I see OGNL classes in exceptions stack trace, I believe it is not as fast as 2+2. But I have never thought to replace ww:property tags with %= % scriplets. ww:property performance is enough for me, for now. WebWork form tags could be really slow. After I have moved templates out of webwork.jar to WEB-INF/template directory, performance improved drastically. Before that my application spent about 90% of CPU time in Freemarker.loadTemplate method. I believe that the test which caused this thread was using form tags. What could be done more to improve performance of form tags? Several months ago I did the following evaluation for my project. Since I was not going to put too much form tags on one page, I had no concerns about its performance impact. But I had a lot of design elements which were used over all pages and could appear many time on one page. I had thought about solution how to make such design elements reusable: 1. JSP include via include directive 2. JSP include vie jsp:include JSP tag 3. using WebWork component tag with own template 4. own WebWork tag with JSP template 5. own WebWork tag with Freemarker template 6. own WebWork tag with Velocity template 7. JSP tag without template (HTML printed directly from Java code out) Test page was create to test performance of these different approaches. The page printed the same component 50 times and printed the time required to render the components (50 components). The component itself represented link to user profile: It was tested on Tomcat 5.5, Windows XP professional, WebWork 2.2.4 Test results: Test Time (ms) to render 50 components 1. include directive 47 2. jsp:include 94 3. ww:component tag with jsp template 109 4. b:jspSimpleProfile tag 79 5. b:ftlSimpleProfile tag 46 6. b:vmSimpleProfile tag 32 7. b:lightProfile tag 0 My conclusions were: - JSP include directive suites for the cases when the included page doesn't contain much logic and is not used often on a page. - jsp:include - better not to use it. Instead of it use include directive - it is faster. If you need to pass additional parameters to the included page, you can put them into value stack. - avoid using ww:component tag. Use JSP include directive instead - it is faster. - if you have much or complex logic and you need complex rendering, create your own UI tag with separated template file - the same way WebWorks does it. Extend your Tag and Component classes from WebWork classes. Use Freemarker template, since it is faster than JSP. Velocity teplates are even faster, but it is better to use Freemarker templates since all WebWork components using it and you can get working examples or event reusable template parts. - if you have simple view but with complex logic or if it used very often - write your own JSP tag with template hardcoded in Java code. Thus I think replacing WebWork/Struts2 form tags by simple JSP tags with HTML hardcoded in Java code will boost performance for tests where form tags are used extensively. But if you would like to have form tags as flexible as they are now, the current implementation is optimal. Their performance is comparable with JSP include directive. I hope that form tags with externalized templates will stay in Struts 2.x :-). You could have two kind of form tags: simple one with hardcoded in Java template and one with Freemarker template. To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135444#135444 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. Would it be possible to contribute the test page you've already started? We have a ticket open. * https://issues.apache.org/struts/browse/WW-1560 I'm also attaching your kind response to the Performance Tuning page as a comment, if that's all right. -Ted. On 3/24/07, Vlad [EMAIL PROTECTED] wrote: When I see OGNL classes in exceptions stack trace, I believe it is not as fast as 2+2. But I have never thought to replace ww:property tags with %= % scriplets. ww:property performance is enough for me, for now. WebWork form tags could be really slow. After I have moved templates out of webwork.jar to WEB-INF/template directory, performance improved drastically. Before that my application spent about 90% of CPU time in Freemarker.loadTemplate method. I believe that the test which caused this thread was using form tags. What could be done more to improve performance of form tags? Several months ago I did the following evaluation for my project. Since I was not going to put too much form tags on one page, I had no concerns about its performance impact. But I had a lot of design elements which were used over all pages and could appear many time on one page. I had thought about solution how to make such design elements reusable: 1. JSP include via include directive 2. JSP include vie jsp:include JSP tag 3. using WebWork component tag with own template 4. own WebWork tag with JSP template 5. own WebWork tag with Freemarker template 6. own WebWork tag with Velocity template 7. JSP tag without template (HTML printed directly from Java code out) Test page was create to test performance of these different approaches. The page printed the same component 50 times and printed the time required to render the components (50 components). The component itself represented link to user profile: It was tested on Tomcat 5.5, Windows XP professional, WebWork 2.2.4 Test results: Test Time (ms) to render 50 components 1. include directive 47 2. jsp:include 94 3. ww:component tag with jsp template 109 4. b:jspSimpleProfile tag 79 5. b:ftlSimpleProfile tag 46 6. b:vmSimpleProfile tag 32 7. b:lightProfile tag 0 My conclusions were: - JSP include directive suites for the cases when the included page doesn't contain much logic and is not used often on a page. - jsp:include - better not to use it. Instead of it use include directive - it is faster. If you need to pass additional parameters to the included page, you can put them into value stack. - avoid using ww:component tag. Use JSP include directive instead - it is faster. - if you have much or complex logic and you need complex rendering, create your own UI tag with separated template file - the same way WebWorks does it. Extend your Tag and Component classes from WebWork classes. Use Freemarker template, since it is faster than JSP. Velocity teplates are even faster, but it is better to use Freemarker templates since all WebWork components using it and you can get working examples or event reusable template parts. - if you have simple view but with complex logic or if it used very often - write your own JSP tag with template hardcoded in Java code. Thus I think replacing WebWork/Struts2 form tags by simple JSP tags with HTML hardcoded in Java code will boost performance for tests where form tags are used extensively. But if you would like to have form tags as flexible as they are now, the current implementation is optimal. Their performance is comparable with JSP include directive. I hope that form tags with externalized templates will stay in Struts 2.x :-). You could have two kind of form tags: simple one with hardcoded in Java template and one with Freemarker template. To avoid such long threads in future, probably it makes sense to add some performance benchmark page in struts examples distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jar to their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jar to their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: OGNL performance detrimental to Struts 2
Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
We could enable the cache when devMode is false. musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: OGNL performance detrimental to Struts 2
As I believe the Ajax/Dojo plugin is ready, if we could mop-up the portlet plugin ticket, we could apply the caching patch to the HEAD, and get started on the 2.1.x series. Having AJAX as a plugin rather than a theme will also benefit many people :) -Ted. On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Yeah, I still need to confirm nothing is broken in core, except the tooltips which I know are not working. By the way Dojo 0.4.2 was released, how was the upgrade made last time? Drop the dojo files and add the new ones? musachy On 3/24/07, Ted Husted [EMAIL PROTECTED] wrote: As I believe the Ajax/Dojo plugin is ready, if we could mop-up the portlet plugin ticket, we could apply the caching patch to the HEAD, and get started on the 2.1.x series. Having AJAX as a plugin rather than a theme will also benefit many people :) -Ted. On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: Well, there is a small risk of things being cached and a developer relying on the behavior of not caching the templates. However, I think those cases will be rare and it would benefit many people. Tom Musachy Barroso wrote: Any reason why this shouldn't be applied on the 2.0 branch instead of 2.1? musachy On 3/24/07, Tom Schneider [EMAIL PROTECTED] wrote: I wrote a struts2 caching implementation of the freemarker templates: https://issues.apache.org/struts/browse/WW-1661 Freemarker wouldn't know how to cache the templates as well as struts2 does since we know how the templates are being used and whether or not it is safe to cache them. Tom Claus Ibsen wrote: From the performance tuning page: Copy the /template directory from the Struts 2 jar in your WEB_APP root. Freemarker fails to properly cache templates when they are retrieved from the classpath. Copying them to the WEB_APP root allows Freemarker to cache them correctly. Freemarker looks at the last modified time of the template to determine if it needs to reload the templates. Resources retrieved from the classpath have no last modified time, so Freemarker will reload them on every request. Isn't it possible to file a JIRA to freemarker so they could improve freemarker to let it be able to cache templates loaded from classpath? I doubt many users know about copying resources from within struts2.jarto their own folder. I think the best is that it just works out-of-the-box. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=53086messageID=135504#135504 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: OGNL performance detrimental to Struts 2
Has anyone rerun these type of benchmarks in light of the performance tuning page? * http://struts.apache.org/2.x/docs/performance-tuning.html -Ted. On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. I would like to know whether the decision-makers for Struts 2 have acknowledged its performance problems and if any resolution has been planned. If so, what timeframe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Not sure what the profiler data looks like but if the profiler is indeed stating that OGNL code is taking the most processor time and it is indeed 5-10 times slower, than the performance tuning page doesn't look like it will address these issues. However, it could simply be the profiler data is actually at a higher level like freemarker or the result classes and then it might be possible to increase performance. I'd be interested to see the profiler data to determine where the issue is. -bp Ted Husted wrote: Has anyone rerun these type of benchmarks in light of the performance tuning page? * http://struts.apache.org/2.x/docs/performance-tuning.html -Ted. On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. I would like to know whether the decision-makers for Struts 2 have acknowledged its performance problems and if any resolution has been planned. If so, what timeframe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Tonight I was looking at abstracting away OGNL from xwork. (I was pretty far before I gave up for the night, about a half dozen OGNL references in xwork that I'll have to look at a little closer) So I took a look at what it would take to integrate MVEL. First, the lack of javadoc is a little disappointing. (There wasn't a single line of javadoc comment that I could find) Secondly, the integration guide isn't very extensive, just some basic examples. Based on these 2 items alone, it may not be as trivial as advertised to figure out how to integrate MVEL into XWork. On the other hand OGNL is not without it's issues. :) I'll probably look at it a bit later when I'm farther with xwork, but that's my take on it thus far for what it's worth. Tom Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: OGNL performance detrimental to Struts 2
We are also seeing very bad performance and I can not say for sure if it is OGNL or something else. Is there an easy way for us to say it is not OGNL. Because if it is OGNL then I would be very interested in seeing some solution for it... because we are planning to go production on this system and by hook or crook we have to solve the performance issue.. -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Monday, December 18, 2006 6:32 PM To: Struts Developers List Subject: Re: OGNL performance detrimental to Struts 2 I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I
Re: OGNL performance detrimental to Struts 2
On 12/29/06, Shekhar Yadav [EMAIL PROTECTED] wrote: We are also seeing very bad performance and I can not say for sure if it is OGNL or something else. Is there an easy way for us to say it is not OGNL. Because if it is OGNL then I would be very interested in seeing some solution for it... because we are planning to go production on this system and by hook or crook we have to solve the performance issue.. Your profiler should tell you pretty quickly how much impact OGNL is having on overall performance in your particular scenario. -- Martin Cooper -Original Message- From: David H. DeWolf [mailto:[EMAIL PROTECTED] On Behalf Of David H. DeWolf Sent: Monday, December 18, 2006 6:32 PM To: Struts Developers List Subject: Re: OGNL performance detrimental to Struts 2 I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use
Re: OGNL performance detrimental to Struts 2
Did you try using the simple theme with Struts 2.0.1 in the benchmarks? -Ted. On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Probably a little early to say for sure, but I don't think anyone needs to worry about ognl performance anymore. I'm sure the right people will update everyone when the time is right. husted wrote: Did you try using the simple theme with Struts 2.0.1 in the benchmarks? -Ted. On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a8056767 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/ s:submit/ /s:form Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where
Re: OGNL performance detrimental to Struts 2
OGNL isn't a subproject of Struts, and so there's not anything we do about changing OGNL from here. AFAIK, everyone in the Struts and WebWork projects have been treating OGNL as black box. The place to start would be by posting to the OGNL developers forum. * http://forums.opensymphony.com/forum.jspa?forumID=16 perhaps accompanied by a JIRA ticket * http://jira.opensymphony.com/browse/OGNL Of course, the forum does seem to be abandoned, but it would still be the place to post a detailed description of what you'd like to do. Once the post is made there, either the OGNL group or the OpenSymphony group would be able respond. -Ted. On 12/18/06, Jessek [EMAIL PROTECTED] wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/
Re: OGNL performance detrimental to Struts 2
I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/ s:submit/ /s:form Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them.
Re: OGNL performance detrimental to Struts 2
I'm not sure what you mean by property accessor. The Tapestry community is just as tied down/used to using ognl expressions as much as any other. Tapestry-prop is a side project Howard created for very specific consulting engagements where the performance overhead of ognl was unacceptable for some clients. I think it's a mistake to throw ognl out at this point. The expression language is awesome, it just needs a performance boost. (it's also been out and about being used for years) Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7940406 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield
Re: OGNL performance detrimental to Struts 2
Me too. On 12/18/06, Don Brown [EMAIL PROTECTED] wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/
Re: OGNL performance detrimental to Struts 2
Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form
Re: OGNL performance detrimental to Struts 2
Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive.
Re: OGNL performance detrimental to Struts 2
I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on expressions in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an enemy project but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive.
Re: OGNL performance detrimental to Struts 2
I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and interceptors to deal with tag objects, not pure text - Tag interceptors or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/ s:submit/ /s:form Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Speaking of tickets, there's one already open * http://issues.apache.org/struts/browse/WW- -Ted. On 12/14/06, Don Brown [EMAIL PROTECTED] wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/ s:submit/ /s:form Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Do you have the performance numbers that you can share? I'd really be interested in them. Also, since you've considering JSF and performance is the deciding faactor, do you have the performance information between s1, s2 and JSF? /Ian dice wrote: The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't have time to rewrite OGNL myself.) In the mean time, we wrote a custom version of OgnlValueStack. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
You may want to take a peek at the svn source tree in t5. It has a slightly better version of these semantics. (though I doubt you'll find any advanced sort of expr support like ognl might provde) That being said, 1ms or so is all it takes to render a lot of tapestry pages, so I wouldn't discount the potential perf savings that quickly.. Bob Lee wrote: I'm not sure I'd worry about it. Howard's post said it only made 1ms difference. Bob On 12/12/06, dice [EMAIL PROTECTED] wrote: The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't have time to rewrite OGNL myself.) In the mean time, we wrote a custom version of OgnlValueStack. -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7853159 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Last time I'll interrupt your normal dev cycle I promise. Since it seems we are both equally screwed in the short term by any non ognl solution it might be beneficial to consider just fixing it. I'm very familiar with javassist bytecode manipulation and vaguely familiar with the internal workings of ognl. It doesn't seem like it would be extremely hard to do. If it didn't look like my time/efforts would be wasted/ignored I might be willing to collaborate with whoever is interested (and able to commit to ognl) on finding a workable solution. Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7856772 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Yes, it does certainly feel easier to just go straight to bytecode. (well, not exactly...I mean you're still basically just passing a String with java code in it to javassist) At least it wouldn't involve as much hashing lookup kind of operations to complete. I'd still be open to doing whatever I can to help, even if it means taking some direction in design suggestions from others. Bob Lee wrote: I wouldn't jump straight to a bytecode solution, there's no reason it should be that much faster than a well-designed plain Java solution. Bob On 12/13/06, Jessek [EMAIL PROTECTED] wrote: Last time I'll interrupt your normal dev cycle I promise. Since it seems we are both equally screwed in the short term by any non ognl solution it might be beneficial to consider just fixing it. I'm very familiar with javassist bytecode manipulation and vaguely familiar with the internal workings of ognl. It doesn't seem like it would be extremely hard to do. If it didn't look like my time/efforts would be wasted/ignored I might be willing to collaborate with whoever is interested (and able to commit to ognl) on finding a workable solution. Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7856772 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7858208 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: s:form action=/test.action method=POST s:textfield label=Label1 name=attribute1/ s:textfield label=Label2 name=attribute2/ s:textfield label=Label3 name=attribute3/ s:textfield label=Label4 name=attribute4/ s:textfield label=Label5 name=attribute5/ s:textfield label=Label6 name=attribute6/ s:textfield label=Label7 name=attribute7/ s:textfield label=Label8 name=attribute8/ s:textfield label=Label9 name=attribute9/ s:textfield label=Nested Label1 name=nestedBean.attribute1/ s:textfield label=Nested Label2 name=nestedBean.attribute2/ s:textfield label=Nested Label3 name=nestedBean.attribute3/ s:textfield label=Nested Label4 name=nestedBean.attribute4/ s:textfield label=Nested Label5 name=nestedBean.attribute5/ s:textfield label=Nested Label6 name=nestedBean.attribute6/ s:textfield label=Nested Label7 name=nestedBean.attribute7/ s:textfield label=Nested Label8 name=nestedBean.attribute8/ s:textfield label=Nested Label9 name=nestedBean.attribute9/ s:submit/ /s:form Ted Husted-3 wrote: On 12/13/06, Ian Roughley [EMAIL PROTECTED] wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our own direct comparisons of S1, S2, et al. Of course, the peformance is the still same as WebWork 2, which is driving some serious applications. We also know exactly where lies the bottleneck. We need to fix or replace OGNL. -Ted. -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7865392 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
On 12/12/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. There's a similar thread on the webwork dev list: http://forums.opensymphony.com/thread.jspa?threadID=52734messageID=106274 I found that in my own own application, the problem was indeed related to OGNL, but mostly for the form tags (things go very well when using simple tags like iterator and property, but you lose everything as soon as the first form/inputfield/select tags enter the game. It was Don who actually pointed me to MVEL. Before, I tried to take a quick stab at bytecode enhancements for OGNL, but lack of experience with the OGNL architecture and ASM interfered with my plans. It also seems my initial performance results about MVEL being 2x slower than OGNL in interpreted mode were misplaced (well, I couldn't get the compilation mode to work), so Chris Brock (its author) kindly sent me some better constructs, which I'll be testing this week. -- Wendy Cheers, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- iDTV System Engineer Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - John F. Woods - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
Would you guys be morally offended if I lifted this code? (or potentially did, need to see how amenable the two are first, but it shouldn't be too hard) I mean, I know licensing is blah blah and all , but you know...Maybe it's not right. Bob Lee wrote: snipped In the mean time, we wrote a custom version of OgnlValueStack (pasted below) which optimizes and uses reflection for normal Java expressions; it's an order of magnitude faster. I think it's 100% compatible (we haven't noticed any problems). snipped -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847251 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't have time to rewrite OGNL myself.) In the mean time, we wrote a custom version of OgnlValueStack. -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I'm not sure I'd worry about it. Howard's post said it only made 1ms difference. Bob On 12/12/06, dice [EMAIL PROTECTED] wrote: The custom OGNLValueStack made little difference. AFAIK, the majority of the OGNL calls are dealing with the tag parameters in the tag templates which are not simple java properties. It's a pity. I was looking forward to using Struts 2 on our next major project but much like JSF it is too risky from a performance perspective. Back to Struts 1 ... *sigh* Bob Lee wrote: We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't have time to rewrite OGNL myself.) In the mean time, we wrote a custom version of OgnlValueStack. -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7847866 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
We noticed the same thing. Maybe we should replace it with JSP-EL? (I don't
have time to rewrite OGNL myself.)
In the mean time, we wrote a custom version of OgnlValueStack (pasted below)
which optimizes and uses reflection for normal Java expressions; it's an
order of magnitude faster. I think it's 100% compatible (we haven't noticed
any problems).
We don't use JSP, so I'm not sure how applicable this would be to other
users. If it is applicable, I'll happily check this in.
Bob
import com.opensymphony.xwork.util.OgnlUtil;
import com.opensymphony.xwork.util.OgnlValueStack;
import ognl.Ognl;
import ognl.OgnlException;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
/**
* Optimizes [EMAIL PROTECTED] #findValue(String, Class)} for expressions that
are Java
* identifiers. Performances tests indicate this is an order of magnitude
faster
* than [EMAIL PROTECTED] OgnlValueStack}. Unlike [EMAIL PROTECTED]
OgnlValueStack}, this
* implementation does not eat exceptions when finding values.
*
* @author [EMAIL PROTECTED] (Bob Lee)
*/
public class FastValueStack extends OgnlValueStack {
static final Object NOT_FOUND = new Object();
MapString, String overrides;
Class defaultType;
public FastValueStack(OgnlValueStack vs) {
super(vs);
}
public FastValueStack() {}
@Override public void setExprOverrides(Map overrides) {
super.setExprOverrides(overrides);
this.overrides = overrides;
}
@Override public void setDefaultType(Class defaultType) {
super.setDefaultType(defaultType);
this.defaultType = defaultType;
}
@Override public Object findValue(String expression, Class asType) {
if (expression == null) {
return null;
}
if (overrides != null overrides.containsKey(expression)) {
expression = (String) overrides.get(expression);
}
if (isJavaIdentifier(expression)) {
Object value = findValueForJavaIdentifier(expression, asType);
if (value != NOT_FOUND) {
return value;
}
}
// fall back to old behavior.
return findValueUsingOgnl(expression, asType);
}
/**
* Tries to find a value when the expression is a java identifier. Returns
* the value or codeNOT_FOUND/code if no qualifying map entry or
accessor
* method is found.
*/
Object findValueForJavaIdentifier(String javaIdentifier, Class asType) {
for (Object o : getRoot()) {
if (o instanceof Map) {
// gets value from a map.
Map m = (Map) o;
if (m.containsKey(javaIdentifier)) {
Object value = m.get(javaIdentifier);
if (value == null || isAssignable(asType, value.getClass())) {
return value;
}
}
} else {
// gets value by invoking a getter.
Getter getter = Getter.getInstance(o.getClass(), javaIdentifier);
if (getter != null
isAssignable(asType, getter.getMethod().getReturnType())) {
return getter.invoke(o);
}
}
}
return NOT_FOUND;
}
Object findValueUsingOgnl(String expression, Class asType) {
try {
Object compiled = OgnlUtil.compile(expression);
return Ognl.getValue(compiled, getContext(), getRoot(), asType);
} catch (OgnlException e) {
throw new RuntimeException(e);
}
}
/**
* Maps primitive classes to their wrapper classes and vice versa.
*/
static MapClass, Class primitiveClassMap = createPrimitiveClassMap();
static MapClass, Class createPrimitiveClassMap() {
MapClass, Class primitiveClassMap = new HashMapClass, Class() {{
put(boolean.class, Boolean.class);
put(char.class, Character.class);
put(short.class, Short.class);
put(int.class, Integer.class);
put(long.class, Long.class);
put(float.class, Float.class);
put(double.class, Double.class);
}};
// add inverted mappings.
MapClass, Class inverted = new HashMapClass, Class();
for (Map.EntryClass, Class entry : primitiveClassMap.entrySet()) {
inverted.put(entry.getValue(), entry.getKey());
}
primitiveClassMap.putAll(inverted);
return primitiveClassMap;
}
/**
* Returns true if you can cast codefromcode to codeto/code.
Allows
* for assignment between primitives and their respective wrapper types.
*
* @param to type to cast to
* @param from actual type
*/
static boolean isAssignable(Class to, Class from) {
if (to.isAssignableFrom(from)) {
return true;
}
Class validFrom = primitiveClassMap.get(to);
if (validFrom != null validFrom.equals(from)) {
return true;
}
return false;
}
static MapString, String javaIdentifiers =
new ConcurrentHashMapString, String();
/**
* Returns true if the string is a valid Java identifier.
*/
static boolean isJavaIdentifier(String s) {
if (javaIdentifiers.containsKey(s)) {
return true;
}
if (s.length() == 0
|| !Character.isJavaIdentifierStart(s.charAt(0))) {
return false;
}
for (int i = 1; i s.length(); i++) {
if
Re: OGNL performance detrimental to Struts 2
Howard, who writes Tapestry, notes the same thing in his framework: http://tapestryjava.blogspot.com/2006/11/improve-tapestry-performance-with.html He chose a different way of retrieving simple properties. It supposedly has jumped his performance a lot. I recommend Struts 2 Committees look for an alternative as well, especially when the expression is simple. Paul dice wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. I would like to know whether the decision-makers for Struts 2 have acknowledged its performance problems and if any resolution has been planned. If so, what timeframe? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
On 12/11/06, dice [EMAIL PROTECTED] wrote: By my own benchmarking I am finding Struts 2 somewhere between 5-10 times slower than Struts 1 in JSP rendering. JProfiler is telling me OGNL is the bottleneck. There's a similar thread on the webwork dev list: http://forums.opensymphony.com/thread.jspa?threadID=52734messageID=106274 -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
