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 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-performan ce.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] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> 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] > > --------------------------------------------------------------------- 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]
