|
»
»
»
MVEL - CLK-306
|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
 |
MVEL - CLK-306
by sabob
::
Rate this Message:
Hi all,
Just a follow up on the issue: ttp://www.avoka.com/jira/browse/CLK-306 Wrote a quick Service class for MVEL and ran it through our PropertyUtilTest. One test failed. MVEL 1.3.x only supports getting properties with a "get" prefix. As one of the tests check against a public property without a "get" prefix the text fails. Is this a killer for us? MVEL 2.0 will address this issue, but MVEL 2.0 might not support Java 1.4 and is only alpha stage currently ;-) Other issues: * Ported our custom Ognl date converter functionality to MVEL. * mvel-1.3.7.jar is about 435KB. If we add MVEL support should we add it as a pluggable Service or simply update PropertyUtils? regards bob ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
I have been thinking about this. I just can't really see much upside
to moving to MVEL. We wont get any significant performance improvement for reading properties, what we are currently doing with reflection and caching appears to be on par with MVEL. Writing properites is not really very performance sensitive, ie form posts are much more infrequent operations, page autobinding might be more significant however. The test failure would be a killer for us, but I presume MVEL can support some form of pluggable adaptor to assist with this. regards Malcolm Edgar On Tue, Jul 22, 2008 at 9:58 PM, bob <sabob1@...> wrote: > Hi all, > > Just a follow up on the issue: ttp://www.avoka.com/jira/browse/CLK-306 > > Wrote a quick Service class for MVEL and ran it through our > PropertyUtilTest. One test failed. MVEL 1.3.x only supports getting > properties with a "get" prefix. As one of the tests check against a > public property without a "get" prefix the text fails. Is this a > killer for us? MVEL 2.0 will address this issue, but MVEL 2.0 might > not support Java 1.4 and is only alpha stage currently ;-) > > Other issues: > * Ported our custom Ognl date converter functionality to MVEL. > * mvel-1.3.7.jar is about 435KB. > > > If we add MVEL support should we add it as a pluggable Service or > simply update PropertyUtils? > > regards > > bob > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Click-development mailing list > Click-development@... > https://lists.sourceforge.net/lists/listinfo/click-development > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
Timing is a bit conincidental,
(https://issues.apache.org/jira/browse/VELOCITY-606) but I have though that after cleaning up the Table rendering performance OGNL issues, we would probably find potential bottle necks in the Velocity stack, and that we might get more bang from our buck by looking at what we could do there. This conjecture however until we have some metrics to look at. Possibley JRat http://jrat.sourceforge.net/prefive.html would be a good tool to start this. regards Malcolm Edgar On Tue, Jul 22, 2008 at 10:18 PM, Malcolm Edgar <malcolm.edgar@...> wrote: > I have been thinking about this. I just can't really see much upside > to moving to MVEL. We wont get any significant performance improvement > for reading properties, what we are currently doing with reflection > and caching appears to be on par with MVEL. Writing properites is not > really very performance sensitive, ie form posts are much more > infrequent operations, page autobinding might be more significant > however. > > The test failure would be a killer for us, but I presume MVEL can > support some form of pluggable adaptor to assist with this. > > regards Malcolm Edgar > > On Tue, Jul 22, 2008 at 9:58 PM, bob <sabob1@...> wrote: >> Hi all, >> >> Just a follow up on the issue: ttp://www.avoka.com/jira/browse/CLK-306 >> >> Wrote a quick Service class for MVEL and ran it through our >> PropertyUtilTest. One test failed. MVEL 1.3.x only supports getting >> properties with a "get" prefix. As one of the tests check against a >> public property without a "get" prefix the text fails. Is this a >> killer for us? MVEL 2.0 will address this issue, but MVEL 2.0 might >> not support Java 1.4 and is only alpha stage currently ;-) >> >> Other issues: >> * Ported our custom Ognl date converter functionality to MVEL. >> * mvel-1.3.7.jar is about 435KB. >> >> >> If we add MVEL support should we add it as a pluggable Service or >> simply update PropertyUtils? >> >> regards >> >> bob >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Click-development mailing list >> Click-development@... >> https://lists.sourceforge.net/lists/listinfo/click-development >> > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by sabob
::
Rate this Message:
Malcolm Edgar wrote:
> The test failure would be a killer for us, but I presume MVEL can > support some form of pluggable adaptor to assist with this. Not until MVEL 2.0: http://jira.codehaus.org/browse/MVEL-71 I think the big gain with MVEL is that complex expressions can be used for Fields and Columns. Another is that MVEL seems to have better support for BigDecimal. But I am comfortable if we postpone this feature until there are more demand. If we agree I will remove it from the M3 roadmap. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by sabob
::
Rate this Message:
Interestingly the benchmark I run for Click performance shows that
Velocity is faster than both FreeMarker and JSP+JSTL. If I recall: Velocity: ~2000 requests per second JSP+JSTL: ~1600 requests per second FreeMarker: ~1600 requests per second Hopefully this does not discourage investigation of performance gains in Velocity :) Malcolm Edgar wrote: > Timing is a bit conincidental, > (https://issues.apache.org/jira/browse/VELOCITY-606) but I have though > that after cleaning up the Table rendering performance OGNL issues, we > would probably find potential bottle necks in the Velocity stack, and > that we might get more bang from our buck by looking at what we could > do there. This conjecture however until we have some metrics to look > at. > > Possibley JRat http://jrat.sourceforge.net/prefive.html would be a > good tool to start this. > > regards Malcolm Edgar > > On Tue, Jul 22, 2008 at 10:18 PM, Malcolm Edgar <malcolm.edgar@...> wrote: >> I have been thinking about this. I just can't really see much upside >> to moving to MVEL. We wont get any significant performance improvement >> for reading properties, what we are currently doing with reflection >> and caching appears to be on par with MVEL. Writing properites is not >> really very performance sensitive, ie form posts are much more >> infrequent operations, page autobinding might be more significant >> however. >> >> The test failure would be a killer for us, but I presume MVEL can >> support some form of pluggable adaptor to assist with this. >> >> regards Malcolm Edgar >> >> On Tue, Jul 22, 2008 at 9:58 PM, bob <sabob1@...> wrote: >>> Hi all, >>> >>> Just a follow up on the issue: ttp://www.avoka.com/jira/browse/CLK-306 >>> >>> Wrote a quick Service class for MVEL and ran it through our >>> PropertyUtilTest. One test failed. MVEL 1.3.x only supports getting >>> properties with a "get" prefix. As one of the tests check against a >>> public property without a "get" prefix the text fails. Is this a >>> killer for us? MVEL 2.0 will address this issue, but MVEL 2.0 might >>> not support Java 1.4 and is only alpha stage currently ;-) >>> >>> Other issues: >>> * Ported our custom Ognl date converter functionality to MVEL. >>> * mvel-1.3.7.jar is about 435KB. >>> >>> >>> If we add MVEL support should we add it as a pluggable Service or >>> simply update PropertyUtils? >>> >>> regards >>> >>> bob >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Click-development mailing list >>> Click-development@... >>> https://lists.sourceforge.net/lists/listinfo/click-development >>> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
JRat is great. I was able to find a hotspot in HtmlStringBuffer which
was pretty significant. ClickUtils was allocating new String values uncessarily when escaping string values. Curious how this change affects your performance test. Hotspot really shows up in the Table control regards Malcolm Edgar On Tue, Jul 22, 2008 at 10:52 PM, bob <sabob1@...> wrote: > Interestingly the benchmark I run for Click performance shows that > Velocity is faster than both FreeMarker and JSP+JSTL. If I recall: > > Velocity: ~2000 requests per second > JSP+JSTL: ~1600 requests per second > FreeMarker: ~1600 requests per second > > Hopefully this does not discourage investigation of performance gains > in Velocity :) > > > Malcolm Edgar wrote: >> Timing is a bit conincidental, >> (https://issues.apache.org/jira/browse/VELOCITY-606) but I have though >> that after cleaning up the Table rendering performance OGNL issues, we >> would probably find potential bottle necks in the Velocity stack, and >> that we might get more bang from our buck by looking at what we could >> do there. This conjecture however until we have some metrics to look >> at. >> >> Possibley JRat http://jrat.sourceforge.net/prefive.html would be a >> good tool to start this. >> >> regards Malcolm Edgar >> >> On Tue, Jul 22, 2008 at 10:18 PM, Malcolm Edgar <malcolm.edgar@...> wrote: >>> I have been thinking about this. I just can't really see much upside >>> to moving to MVEL. We wont get any significant performance improvement >>> for reading properties, what we are currently doing with reflection >>> and caching appears to be on par with MVEL. Writing properites is not >>> really very performance sensitive, ie form posts are much more >>> infrequent operations, page autobinding might be more significant >>> however. >>> >>> The test failure would be a killer for us, but I presume MVEL can >>> support some form of pluggable adaptor to assist with this. >>> >>> regards Malcolm Edgar >>> >>> On Tue, Jul 22, 2008 at 9:58 PM, bob <sabob1@...> wrote: >>>> Hi all, >>>> >>>> Just a follow up on the issue: ttp://www.avoka.com/jira/browse/CLK-306 >>>> >>>> Wrote a quick Service class for MVEL and ran it through our >>>> PropertyUtilTest. One test failed. MVEL 1.3.x only supports getting >>>> properties with a "get" prefix. As one of the tests check against a >>>> public property without a "get" prefix the text fails. Is this a >>>> killer for us? MVEL 2.0 will address this issue, but MVEL 2.0 might >>>> not support Java 1.4 and is only alpha stage currently ;-) >>>> >>>> Other issues: >>>> * Ported our custom Ognl date converter functionality to MVEL. >>>> * mvel-1.3.7.jar is about 435KB. >>>> >>>> >>>> If we add MVEL support should we add it as a pluggable Service or >>>> simply update PropertyUtils? >>>> >>>> regards >>>> >>>> bob >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> Click-development mailing list >>>> Click-development@... >>>> https://lists.sourceforge.net/lists/listinfo/click-development >>>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Click-development mailing list > Click-development@... > https://lists.sourceforge.net/lists/listinfo/click-development > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by sabob
::
Rate this Message:
Hi Malcolm,
Malcolm Edgar wrote: > JRat is great. I was able to find a hotspot in HtmlStringBuffer which > was pretty significant. > > ClickUtils was allocating new String values uncessarily when escaping > string values. Nice. Did you run JRat through the examples with JMeter or how did you pickup this hotspot? Have not used JRat yet, but is it better than say YourKit for finding perf problems? > Curious how this change affects your performance test. This change does not effect the benchmark. With or without the change to HtmlStringBuffer I get 1520 requests per second. But then again only 200 characters are escaped during the test... Out of curiosity I changed the appendEscaped implementation to simply append the object instead of escaping it and I get 1630 request per second. Roughly 7% increase. Meaning the check inside appendEscapeChar takes a bit of overhead. kind regards bob ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by sabob
::
Rate this Message:
bob wrote:
> > Out of curiosity I changed the appendEscaped implementation to simply > append the object instead of escaping it and I get 1630 request per > second. Roughly 7% increase. Meaning the check inside appendEscapeChar > takes a bit of overhead. When the appendEscapeChar is taken out of the hotspot equation, interesting results follow. For example Decorator#render method is not optimal since it does not pass through the buffer to render from. And calls to getContext() is cheap, but not free. There are a number of controls which makes multiple calls to getContext in the same method. Better to cache context inside the method call. I think I'll fix these methods to cache context... ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
On Wed, Jul 23, 2008 at 7:47 PM, bob <sabob1@...> wrote:
> Hi Malcolm, > > Malcolm Edgar wrote: >> JRat is great. I was able to find a hotspot in HtmlStringBuffer which >> was pretty significant. >> >> ClickUtils was allocating new String values uncessarily when escaping >> string values. > > Nice. Did you run JRat through the examples with JMeter or how did you > pickup this hotspot? > > Have not used JRat yet, but is it better than say YourKit for finding > perf problems? This was picked up using JRat collecting metrics from Tomcat 5.5 running click-examples Advanced Table example. http://localhost:8080/click-examples/introduction/advanced-table.htm I thought this would be fairly representative of a typical screen. Reviewing the Click classes in JRat highlighted this issue. >> Curious how this change affects your performance test. > > This change does not effect the benchmark. With or without the change > to HtmlStringBuffer I get 1520 requests per second. But then again > only 200 characters are escaped during the test... > > Out of curiosity I changed the appendEscaped implementation to simply > append the object instead of escaping it and I get 1630 request per > second. Roughly 7% increase. Meaning the check inside appendEscapeChar > takes a bit of overhead. > > kind regards > > bob > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Click-development mailing list > Click-development@... > https://lists.sourceforge.net/lists/listinfo/click-development > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
On Wed, Jul 23, 2008 at 9:35 PM, bob <sabob1@...> wrote:
> bob wrote: >> >> Out of curiosity I changed the appendEscaped implementation to simply >> append the object instead of escaping it and I get 1630 request per >> second. Roughly 7% increase. Meaning the check inside appendEscapeChar >> takes a bit of overhead. > > When the appendEscapeChar is taken out of the hotspot equation, > interesting results follow. For example Decorator#render method is not > optimal since it does not pass through the buffer to render from. Yes, starts to highlight this again doesn't it. > And calls to getContext() is cheap, but not free. There are a number > of controls which makes multiple calls to getContext in the same > method. Better to cache context inside the method call. I think I'll > fix these methods to cache context... > Yes I saw this being highlighted, and was thinking about this today. I have done some experimentation with having a transient Context variable reference to cache to lookup, but this causes issues with stateful pages, as it refers to old contexts. However if we nullify this reference in the onDestroy() method I think this would work fine. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Click-development mailing list > Click-development@... > https://lists.sourceforge.net/lists/listinfo/click-development > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
|
|
Re: MVEL - CLK-306
by Malcolm Edgar-2
::
Rate this Message:
Caching the context and nullifying it onDestroy() did not work with
stateful pages, obviously I was not fully considering the context stack. Have rolled this back. Have started on the optional column id attribute rendering. This should improve things quite a bit. regards Malcolm Edgar On Thu, Jul 24, 2008 at 8:49 AM, Malcolm Edgar <malcolm.edgar@...> wrote: > On Wed, Jul 23, 2008 at 9:35 PM, bob <sabob1@...> wrote: >> bob wrote: >>> >>> Out of curiosity I changed the appendEscaped implementation to simply >>> append the object instead of escaping it and I get 1630 request per >>> second. Roughly 7% increase. Meaning the check inside appendEscapeChar >>> takes a bit of overhead. >> >> When the appendEscapeChar is taken out of the hotspot equation, >> interesting results follow. For example Decorator#render method is not >> optimal since it does not pass through the buffer to render from. > > Yes, starts to highlight this again doesn't it. > >> And calls to getContext() is cheap, but not free. There are a number >> of controls which makes multiple calls to getContext in the same >> method. Better to cache context inside the method call. I think I'll >> fix these methods to cache context... >> > Yes I saw this being highlighted, and was thinking about this today. I > have done some experimentation with having a transient Context > variable reference to cache to lookup, but this causes issues with > stateful pages, as it refers to old contexts. However if we nullify > this reference in the onDestroy() method I think this would work fine. > >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Click-development mailing list >> Click-development@... >> https://lists.sourceforge.net/lists/listinfo/click-development >> > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Click-development mailing list Click-development@... https://lists.sourceforge.net/lists/listinfo/click-development |
| Free Forum Powered by Nabble | Forum Help |