Re: MVEL?
Well, that's one way of implementing a cache. Even if you did do that, the
performance gain from compiling the expression is on the order of a
magnitude (or greater), so any contention in the hash lookup would be far
worth it. However, there are other more efficient strategies that have been
employed through the use of external code generation, and tying compiled
expressions directly to the instance of a JSP tag.
But we're talking about web-based stuff here. MVEL is used for a broad
range of stuff, like actual scripting in Smooks and JBoss Drools. It's used
for straight-up data binding in jBPM and JBoss ESB. It's used for some
custom UI stuff in Mule Galaxy, etc.
To you P.S.: MVEL works directly on the expression by using a sliding window
algorithm. Think of it like this.
0 { f }
1 { o }
2 { o }
3 { . }
4 { b }
5 { a }
6 { r }
7 { [ }
8 { 0 }
9 { ] }
MVEL takes the string as an array. It holds a start position, and a cursor
position.
When it starts parsing, it starts scanning until it finds the first
non-identifier character, which is '.'. At this point it does a capture. At
this point: start=0; cursor=3; This represents the boundary of the first
token. We then process the token by converting it to a String, marking the
start position as cursor+1 and repeat. When we hit the next non-identifier
which is '[' MVEL knows this is a index accessor and acts appropriately,
following the same principle.
MVEL does this inline with actual evaluation. It works out to be
significantly more efficient than StringTokenizer and also allows you to
incrementally add complexity over time.
Unfortunately, it becomes increasing more difficult to maintain a design
like this, especially as it evolves into more sophisticated constructs.
You're welcome to contact me directly in e-mail to discuss this, as I don't
want to pollute the Struts mailing list with non-Struts related talk.
Brian Pontarelli wrote:
>
> Not sure I follow. If I compile an expression, how can I reuse the
> compiled version? I would assume it would need to be in a cache where
> the key is the expression String and the value is the compiled
> version. Correct me if I'm wrong.
>
> -bp
>
> P.S. based on your knowledge, I'm wondering if JCatapult would perform
> better if the expression wasn't divided into its pieces but rather
> evaluated character by character until a boundary is hit, at which
> time that portion is evaluated? I wouldn't think this would increase
> performance drastically, but you would know much better than I.
>
>
>
> On Oct 12, 2008, at 8:38 PM, Chris Brock wrote:
>
>>
>> " I'd also be interested to hear a
>> good discussion about caching compiled MVEL expressions and whether or
>> not thread contention for the cache is an issue at all"
>>
>> There is no contention in the cache. MVEL returns self-contained,
>> stateless, evaluation trees (or bytecode via the JIT) that do not
>> require
>> synchronization or contention in multi-threaded scenarios. The
>> payload
>> returned by the compiler is essentially stateless code, and there is
>> no
>> "cache" that is used such as reflection cache or otherwise as there
>> is in
>> things like Commons EL, or JEXL. This is actually, from an
>> architectural
>> perspective what makes MVEL stand apart from these technologies.
>>
>>
>> Brian Pontarelli wrote:
>>>
>>>> Sure. But OGNL will return similar results with 50 tests. Yet
>>>> people have
>>>> run into performance problems. The issue is that you're not looking
>>>> at
>>>> performance in terms of resource contention, and in terms of
>>>> aggregate
>>>> resource usage.
>>>
>>> I'd say that for web application expressions OGNL and MVEL are about
>>> equal then. In fact, I've never wanted to replace OGNL for
>>> performance
>>> reasons. It was for primarily other reasons.
>>>
>>>>
>>>> Say you have a page which contains 20 expressions. And your pages
>>>> are
>>>> getting hit 15 times a second (a reality in some high traffic
>>>> sites).
>>>> That's 300 expressions running every second. Now, in insolation
>>>> that's
>>>> probably chump change. But as resource contention rises in these
>>>> situation,
>>>> the overall efficiency drops and resource usage is exaggerated as a
>>>> result.
>>>
>>> I've worked with this level of traffic and higher and it is still not
>>> an issue to be setting
Re: MVEL?
First public beta of MVEL 2.0, I mean :) Chris Brock wrote: > > "However, under one test condition, MVEL never returned and caused a > load of 50 on my box. It was quite distressing, but it looked like > MVEL got into a bunch of infinite loops or something. I let it run at > a load of 50 for a while and then I had to kill it, but none of the > threads had finished yet. " > > This is the first public beta of MVEL. Much of the code has not been > publicly flushed out. So we do expect bugs. But I'd be particularly > interested in trying to recreate the conditions of this. > > > Brian Pontarelli wrote: >> >>> Sure. But OGNL will return similar results with 50 tests. Yet >>> people have >>> run into performance problems. The issue is that you're not looking >>> at >>> performance in terms of resource contention, and in terms of aggregate >>> resource usage. >> >> I'd say that for web application expressions OGNL and MVEL are about >> equal then. In fact, I've never wanted to replace OGNL for performance >> reasons. It was for primarily other reasons. >> >>> >>> Say you have a page which contains 20 expressions. And your pages are >>> getting hit 15 times a second (a reality in some high traffic sites). >>> That's 300 expressions running every second. Now, in insolation >>> that's >>> probably chump change. But as resource contention rises in these >>> situation, >>> the overall efficiency drops and resource usage is exaggerated as a >>> result. >> >> I've worked with this level of traffic and higher and it is still not >> an issue to be setting 20 values for 1ms per request. >> >> >>> >>> You might in term start to find that what is only 0ms in an isolate >>> closed-loop test (which is not a very good way to benchmark in Java, >>> by the >>> way) could very well be something that contributes to a significant >>> amount >>> of CPU time in systems with high load. >> >> Probably not in this case though and the scale between 1 iteration and >> 50 is decent testament to that. It the CPU was pinned it would be more >> linear. >> >> >>> >>> Take these real benchmarks (from MVEL 1.2--which is old): >>> >>> Test Name: Deep Property >>> Expression : foo.bar.name >>> Iterations : 5 >>> Interpreted Results : >>> (OGNL) : 1955.20ms avg. (mem delta: -790kb) >>> [1936,1949,1943,1994,1954] >>> (MVEL) : 114.80ms avg. (mem delta: -112kb) >>> [119,113,110,117,115] >>> Compiled Results : >>> (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) >>> [92,92,92,92,96] >>> (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] >> >> Here's what I got for 50K on my box using MVEL and JCatapult side by >> side: >> >> MVEL 808ms >> JCatapult 1200ms >> >> MVEL had a hit for the first method call, but it was only 40ms. >> Otherwise, they performed exactly the same for anything up to 50 >> iterations. MVEL often poked above 1ms for single iterations, while >> JCatapult never did, but that's negligible for both. JCatapult is >> definitely slower as the iterations go up. >> >> I tossed in a thread test with 50 threads each running 50K iterations >> and the averages were: >> >> MVEL 8000ms >> JCatapult 23000ms >> >> However, under one test condition, MVEL never returned and caused a >> load of 50 on my box. It was quite distressing, but it looked like >> MVEL got into a bunch of infinite loops or something. I let it run at >> a load of 50 for a while and then I had to kill it, but none of the >> threads had finished yet. >> >> I also did a 50 thread and 50 iteration test and the averages were >> roughly: >> >> MVEL 30ms >> JCatapult 120ms >> >> Except for the case above, MVEL definitely out-performs JCatapult. >> >> >>> >>> ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a >>> 1000x more >>> iterations than your benchmark. If I divide 114.8ms / 1000 ... I >>> get 0.1ms >>> (or what would otherwise be rounded down to 0ms). In OGNL's case, it >>> did 50 >>> iterations in 1.95ms (or what would be measured as 1ms -- as these >>> time &
Re: MVEL?
" I'd also be interested to hear a good discussion about caching compiled MVEL expressions and whether or not thread contention for the cache is an issue at all" There is no contention in the cache. MVEL returns self-contained, stateless, evaluation trees (or bytecode via the JIT) that do not require synchronization or contention in multi-threaded scenarios. The payload returned by the compiler is essentially stateless code, and there is no "cache" that is used such as reflection cache or otherwise as there is in things like Commons EL, or JEXL. This is actually, from an architectural perspective what makes MVEL stand apart from these technologies. Brian Pontarelli wrote: > >> Sure. But OGNL will return similar results with 50 tests. Yet >> people have >> run into performance problems. The issue is that you're not looking >> at >> performance in terms of resource contention, and in terms of aggregate >> resource usage. > > I'd say that for web application expressions OGNL and MVEL are about > equal then. In fact, I've never wanted to replace OGNL for performance > reasons. It was for primarily other reasons. > >> >> Say you have a page which contains 20 expressions. And your pages are >> getting hit 15 times a second (a reality in some high traffic sites). >> That's 300 expressions running every second. Now, in insolation >> that's >> probably chump change. But as resource contention rises in these >> situation, >> the overall efficiency drops and resource usage is exaggerated as a >> result. > > I've worked with this level of traffic and higher and it is still not > an issue to be setting 20 values for 1ms per request. > > >> >> You might in term start to find that what is only 0ms in an isolate >> closed-loop test (which is not a very good way to benchmark in Java, >> by the >> way) could very well be something that contributes to a significant >> amount >> of CPU time in systems with high load. > > Probably not in this case though and the scale between 1 iteration and > 50 is decent testament to that. It the CPU was pinned it would be more > linear. > > >> >> Take these real benchmarks (from MVEL 1.2--which is old): >> >> Test Name: Deep Property >> Expression : foo.bar.name >> Iterations : 5 >> Interpreted Results : >> (OGNL) : 1955.20ms avg. (mem delta: -790kb) >> [1936,1949,1943,1994,1954] >> (MVEL) : 114.80ms avg. (mem delta: -112kb) >> [119,113,110,117,115] >> Compiled Results : >> (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) >> [92,92,92,92,96] >> (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] > > Here's what I got for 50K on my box using MVEL and JCatapult side by > side: > > MVEL 808ms > JCatapult 1200ms > > MVEL had a hit for the first method call, but it was only 40ms. > Otherwise, they performed exactly the same for anything up to 50 > iterations. MVEL often poked above 1ms for single iterations, while > JCatapult never did, but that's negligible for both. JCatapult is > definitely slower as the iterations go up. > > I tossed in a thread test with 50 threads each running 50K iterations > and the averages were: > > MVEL 8000ms > JCatapult 23000ms > > However, under one test condition, MVEL never returned and caused a > load of 50 on my box. It was quite distressing, but it looked like > MVEL got into a bunch of infinite loops or something. I let it run at > a load of 50 for a while and then I had to kill it, but none of the > threads had finished yet. > > I also did a 50 thread and 50 iteration test and the averages were > roughly: > > MVEL 30ms > JCatapult 120ms > > Except for the case above, MVEL definitely out-performs JCatapult. > > >> >> ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a >> 1000x more >> iterations than your benchmark. If I divide 114.8ms / 1000 ... I >> get 0.1ms >> (or what would otherwise be rounded down to 0ms). In OGNL's case, it >> did 50 >> iterations in 1.95ms (or what would be measured as 1ms -- as these >> time >> measurements always round down because of the fact currentTimeMillis() >> returns the result in MS). > > Although JCatapult is slower, I'd be careful with such math because it > isn't always as linear as this. > > > >> >> >> You can talk about "good enough" all you want, but faster is always >> better >> when it comes to scale. :) > > I know a lot about scale and this is not the only truth. In fact, for > what we are talking about, good enough should be just fine. Most scale > problems occur because of bottlenecks and I doubt that our case of web > applications and setting parameters is a bottleneck. > > However, I'm definitely welcome to suggestions on improvements for my > quite simple expression evaluator. I'd also be interested to hear a > good discussion about caching compiled MVEL expressions and whether or > not
Re: MVEL?
"However, under one test condition, MVEL never returned and caused a load of 50 on my box. It was quite distressing, but it looked like MVEL got into a bunch of infinite loops or something. I let it run at a load of 50 for a while and then I had to kill it, but none of the threads had finished yet. " This is the first public beta of MVEL. Much of the code has not been publicly flushed out. So we do expect bugs. But I'd be particularly interested in trying to recreate the conditions of this. Brian Pontarelli wrote: > >> Sure. But OGNL will return similar results with 50 tests. Yet >> people have >> run into performance problems. The issue is that you're not looking >> at >> performance in terms of resource contention, and in terms of aggregate >> resource usage. > > I'd say that for web application expressions OGNL and MVEL are about > equal then. In fact, I've never wanted to replace OGNL for performance > reasons. It was for primarily other reasons. > >> >> Say you have a page which contains 20 expressions. And your pages are >> getting hit 15 times a second (a reality in some high traffic sites). >> That's 300 expressions running every second. Now, in insolation >> that's >> probably chump change. But as resource contention rises in these >> situation, >> the overall efficiency drops and resource usage is exaggerated as a >> result. > > I've worked with this level of traffic and higher and it is still not > an issue to be setting 20 values for 1ms per request. > > >> >> You might in term start to find that what is only 0ms in an isolate >> closed-loop test (which is not a very good way to benchmark in Java, >> by the >> way) could very well be something that contributes to a significant >> amount >> of CPU time in systems with high load. > > Probably not in this case though and the scale between 1 iteration and > 50 is decent testament to that. It the CPU was pinned it would be more > linear. > > >> >> Take these real benchmarks (from MVEL 1.2--which is old): >> >> Test Name: Deep Property >> Expression : foo.bar.name >> Iterations : 5 >> Interpreted Results : >> (OGNL) : 1955.20ms avg. (mem delta: -790kb) >> [1936,1949,1943,1994,1954] >> (MVEL) : 114.80ms avg. (mem delta: -112kb) >> [119,113,110,117,115] >> Compiled Results : >> (OGNL Compiled) : 92.80ms avg. (mem delta: -580kb) >> [92,92,92,92,96] >> (MVEL Compiled) : 1.80ms avg. (mem delta: -18kb) [1,2,2,2,2] > > Here's what I got for 50K on my box using MVEL and JCatapult side by > side: > > MVEL 808ms > JCatapult 1200ms > > MVEL had a hit for the first method call, but it was only 40ms. > Otherwise, they performed exactly the same for anything up to 50 > iterations. MVEL often poked above 1ms for single iterations, while > JCatapult never did, but that's negligible for both. JCatapult is > definitely slower as the iterations go up. > > I tossed in a thread test with 50 threads each running 50K iterations > and the averages were: > > MVEL 8000ms > JCatapult 23000ms > > However, under one test condition, MVEL never returned and caused a > load of 50 on my box. It was quite distressing, but it looked like > MVEL got into a bunch of infinite loops or something. I let it run at > a load of 50 for a while and then I had to kill it, but none of the > threads had finished yet. > > I also did a 50 thread and 50 iteration test and the averages were > roughly: > > MVEL 30ms > JCatapult 120ms > > Except for the case above, MVEL definitely out-performs JCatapult. > > >> >> ... 50,000 iterations on MVEL interpreted in 114.80ms. This is a >> 1000x more >> iterations than your benchmark. If I divide 114.8ms / 1000 ... I >> get 0.1ms >> (or what would otherwise be rounded down to 0ms). In OGNL's case, it >> did 50 >> iterations in 1.95ms (or what would be measured as 1ms -- as these >> time >> measurements always round down because of the fact currentTimeMillis() >> returns the result in MS). > > Although JCatapult is slower, I'd be careful with such math because it > isn't always as linear as this. > > > >> >> >> You can talk about "good enough" all you want, but faster is always >> better >> when it comes to scale. :) > > I know a lot about scale and this is not the only truth. In fact, for > what we are talking about, good enough should be just fine. Most scale > problems occur because of bottlenecks and I doubt that our case of web > applications and setting parameters is a bottleneck. > > However, I'm definitely welcome to suggestions on improvements for my > quite simple expression evaluator. I'd also be interested to hear a > good discussion about caching compiled MVEL expressions and whether or > not thread contention for the cache is an issue at all. Unfortunately, > because JCatapult uses my concept of dynamic attributes quite heavily, > it might b
Re: MVEL?
... I should note that in 2.0b1 the generic type observance is not completely
implemented for set expressions, since we have not augmented the API to
accept a ParserContext object to turn this on (which is required by the
compiler). It is possible to mimic set expressions with the regular
compiler, but there's no point in benchmarking a hack at this point. 2.0b2
will have the API issue resolved with overloaded compileSetExpression()
methods that accept a ParserContext parameter. Anyways...
// interpreted
MVEL.setProperty(contextObject, "foo.property", value);
--snip-snip--
// compiled
Serializable s = MVEL.compileSetExpression("foo.property");
MVEL.executeSetExpression(s, contextObject, value);
Brian Pontarelli wrote:
>
> Send me the code to set values which will require object construction
> and generic inspection and handling as well.
>
> Thanks,
> -bp
>
>
> On Oct 12, 2008, at 6:35 PM, Chris Brock wrote:
>
>>
>>
>> Assuming you're using a context-root, you'd write it like this:
>>
>> long start = System.currentTimeMillis();
>> for (int i = 0; i < iterations; i++ {
>> MVEL.eval("foo.bar", entityObj); // equivalent of:
>> entityObj.getFoo().getBar();
>> }
>> System.out.println("interpreted time: " +
>> (System.currentTimeMillis()-start));
>>
>> You can also compare MVEL's compiled performance like so:
>>
>> Serializable s = MVEL.compileExpression("foo.bar");
>> long start = System.currentTimeMillis();
>> for (int i = 0; i < iterations; i++) {
>> MVEL.executeExpression(s, entityObj);
>> }
>> System.out.println("compiled time: " + (System.currentTimeMillis()-
>> start));
>>
>>
>>
>> Brian Pontarelli wrote:
>>>
>>>
>>> Send me code for MVEL and I'll run both. It will be much easier for
>>> you to write good MVEL code than me.
>>>
>>> -bp
>>>
>>>
>>> On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
>>>
>>>>
>>>> I actually tried to do this really quickly earlier. I didn't have
>>>> time to
>>>> figure it out, as your EL stuff has dependencies on
>>>> HttpServletRequest and
>>>> outward dependencies to your framework. I tried to check-out
>>>> everything,
>>>> but SVN kept dying while checking out (I think Google's SVN server
>>>> was
>>>> acting up).
>>>>
>>>> One of the problems of trying to do a simple performance test with
>>>> your
>>>> stuff is that (like you say) it's not generic, and a bit of a pain
>>>> in the
>>>> butt to test in isolation.
>>>>
>>>>
>>>> Brian Pontarelli wrote:
>>>>>
>>>>>
>>>>> We could do that if you like. Those are pretty simple numbers with
>>>>> very straight-forward cases. So, please run those against MVEL and
>>>>> let
>>>>> me know what you get. StringTokenizer is obviously quite fast,
>>>>> and I
>>>>> could easily remove it if it would mean sub-millisecond times,
>>>>> although the work probably isn't worth the effort with such small
>>>>> numbers.
>>>>>
>>>>> Just create three classes:
>>>>>
>>>>> An action
>>>>> A user object
>>>>> An address object
>>>>>
>>>>> The action has a user and the user has a generic Map of addresses
>>>>> keyed off a String. This should work:
>>>>>
>>>>> public class Action
>>>>> public User user;
>>>>> }
>>>>>
>>>>> public class User {
>>>>> public int age;
>>>>> public Map addresses;
>>>>> }
>>>>>
>>>>> public class Address {
>>>>> public String zipcode;
>>>>> }
>>>>>
>>>>> Then, just get and set some values without any pre-compile or
>>>>> caching
>>>>> and let me know what the times are. My guess is that you will be
>>>>> slightly slower or the same. To get truly accurate, we might have
>>>>> to
>>>>> go sub-millisecond or create some more dramatic tests.
>>>>>
>>>>> Also, I doubt that StringTokenizer is impacting my performance any.
>>>>> In
>>>>> fact the numbers cle
Re: MVEL?
Assuming you're using a context-root, you'd write it like this:
long start = System.currentTimeMillis();
for (int i = 0; i < iterations; i++ {
MVEL.eval("foo.bar", entityObj); // equivalent of:
entityObj.getFoo().getBar();
}
System.out.println("interpreted time: " +
(System.currentTimeMillis()-start));
You can also compare MVEL's compiled performance like so:
Serializable s = MVEL.compileExpression("foo.bar");
long start = System.currentTimeMillis();
for (int i = 0; i < iterations; i++) {
MVEL.executeExpression(s, entityObj);
}
System.out.println("compiled time: " + (System.currentTimeMillis()-start));
Brian Pontarelli wrote:
>
>
> Send me code for MVEL and I'll run both. It will be much easier for
> you to write good MVEL code than me.
>
> -bp
>
>
> On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
>
>>
>> I actually tried to do this really quickly earlier. I didn't have
>> time to
>> figure it out, as your EL stuff has dependencies on
>> HttpServletRequest and
>> outward dependencies to your framework. I tried to check-out
>> everything,
>> but SVN kept dying while checking out (I think Google's SVN server was
>> acting up).
>>
>> One of the problems of trying to do a simple performance test with
>> your
>> stuff is that (like you say) it's not generic, and a bit of a pain
>> in the
>> butt to test in isolation.
>>
>>
>> Brian Pontarelli wrote:
>>>
>>>
>>> We could do that if you like. Those are pretty simple numbers with
>>> very straight-forward cases. So, please run those against MVEL and
>>> let
>>> me know what you get. StringTokenizer is obviously quite fast, and I
>>> could easily remove it if it would mean sub-millisecond times,
>>> although the work probably isn't worth the effort with such small
>>> numbers.
>>>
>>> Just create three classes:
>>>
>>> An action
>>> A user object
>>> An address object
>>>
>>> The action has a user and the user has a generic Map of addresses
>>> keyed off a String. This should work:
>>>
>>> public class Action
>>> public User user;
>>> }
>>>
>>> public class User {
>>> public int age;
>>> public Map addresses;
>>> }
>>>
>>> public class Address {
>>> public String zipcode;
>>> }
>>>
>>> Then, just get and set some values without any pre-compile or caching
>>> and let me know what the times are. My guess is that you will be
>>> slightly slower or the same. To get truly accurate, we might have to
>>> go sub-millisecond or create some more dramatic tests.
>>>
>>> Also, I doubt that StringTokenizer is impacting my performance any.
>>> In
>>> fact the numbers clearly state otherwise. Besides, with things
>>> happening sub-millisecond or just above that, I just don't see any
>>> benefit in spending a lot of time making it faster.
>>>
>>> -bp
>>>
>>>
>>>
>>> On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
>>>
>>>>
>>>> Well, I'd like to see an actual comparison. I somehow doubt your
>>>> parser,
>>>> which I note is using StringTokenizer will perform as well as MVEL's
>>>> parser,
>>>> which is a much more computationally efficient sliding-window
>>>> parser.
>>>>
>>>>
>>>> Brian Pontarelli wrote:
>>>>>
>>>>> Right, but you can receive similar or better performance using a
>>>>> linear runtime evaluation if the language is simple enough and
>>>>> tuned
>>>>> for the web. And as you and I say, MVEL and most other languages
>>>>> aren't targeted to the web and have many extra features.
>>>>>
>>>>> I can't really believe that JUEL is that slow though. And if it
>>>>> really
>>>>> is, it should be extremely simple to make it just as fast as MVEL.
>>>>> But
>>>>> I couldn't say for certain because I don't know the code.
>>>>>
>>>>> I ran some simple tests on getting and setting properties for the
>>>>> JCatapult expression evaluator and here's what I got:
>>>>>
>>>>> Retrieving from a JavaBean property ("user.age") 1ms
>>>>> Retrieving from a
Re: MVEL?
currentTimeMillis();
> evaluator.getValue("user.addresses['home'].zipcode", action);
> end = System.currentTimeMillis();
> System.out.println("Getting field time was " + (end - start));
>
> action = new Action();
> start = System.currentTimeMillis();
> evaluator.getValue("user.age", action);
> end = System.currentTimeMillis();
> System.out.println("Getting property time was " + (end -
> start));
>
> start = System.currentTimeMillis();
> evaluator.getValue("user.addresses['home'].zipcode", action);
> end = System.currentTimeMillis();
> System.out.println("Getting property time was " + (end -
> start));
>
> // Loop
>
> start = System.currentTimeMillis();
> for (int i = 0; i < 50; i++) {
> evaluator.getValue("user.addresses['home'].zipcode",
> action);
> }
> end = System.currentTimeMillis();
> System.out.println("50 times was " + (end - start));
> }
>
> And the output:
>
> [junit] Setting field time was 0
> [junit] Setting field time was 0
> [junit] Setting property time was 0
> [junit] Setting proeprty time was 0
> [junit] Getting field time was 0
> [junit] Getting field time was 0
> [junit] Getting property time was 0
> [junit] Getting property time was 0
> [junit] 50 times was 2
>
> That's definitely fast enough for any web application.
>
> -bp
>
> On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
>
>>
>> Well, I'd like to see an actual comparison. I somehow doubt your
>> parser,
>> which I note is using StringTokenizer will perform as well as MVEL's
>> parser,
>> which is a much more computationally efficient sliding-window parser.
>>
>>
>> Brian Pontarelli wrote:
>>>
>>> Right, but you can receive similar or better performance using a
>>> linear runtime evaluation if the language is simple enough and tuned
>>> for the web. And as you and I say, MVEL and most other languages
>>> aren't targeted to the web and have many extra features.
>>>
>>> I can't really believe that JUEL is that slow though. And if it
>>> really
>>> is, it should be extremely simple to make it just as fast as MVEL.
>>> But
>>> I couldn't say for certain because I don't know the code.
>>>
>>> I ran some simple tests on getting and setting properties for the
>>> JCatapult expression evaluator and here's what I got:
>>>
>>> Retrieving from a JavaBean property ("user.age") 1ms
>>> Retrieving from a public member field ("user.age") < 1ms
>>> Retrieving from a nested JavaBean property within a collection
>>> ("user.addresses['home'].zipcode") 1ms
>>> Retrieving from a nested public member field within a collection
>>> ("user.addresses['home'].zipcode") 1ms
>>>
>>> Setting a JavaBean property with type conversion ("user.age") 1ms
>>> Setting a nested JavaBean property, with collections and Object
>>> creation ("user.addresses['home'].zipcode") 2ms
>>>
>>> That's definitely fast enough for my web applications. ;)
>>>
>>> JCatapult does support using public member fields of classes and it
>>> does shave a little bit of time, but nothing that would make a huge
>>> difference. These are all runtime parsing and handling, nothing is
>>> compiled or cached.
>>>
>>> -bp
>>>
>>> On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
>>>
>>>>
>>>> The singleton pattern is used in MVEL, with knowledge of the
>>>> tradeoff. MVEL
>>>> has a strong emphasis on maintaining interpreted-mode performance.
>>>>
>>>> MVEL contains two runtime systems: an interpreter, and a compiler/
>>>> runtime.
>>>> Unlike other ELs, MVEL does not simply bootstrap the compiler, and
>>>> execute
>>>> that way. Instead, MVEL has a real-time interpreter which evaluates
>>>> to a
>>>> stack during parsing. Therefore, the general design decisions,
>>>> particularly
>>>> around extendability tend to favor singleton-patterns, instead of
>>>> heavyweight configuration sessions which would com
Re: MVEL?
I actually tried to do this really quickly earlier. I didn't have time to
figure it out, as your EL stuff has dependencies on HttpServletRequest and
outward dependencies to your framework. I tried to check-out everything,
but SVN kept dying while checking out (I think Google's SVN server was
acting up).
One of the problems of trying to do a simple performance test with your
stuff is that (like you say) it's not generic, and a bit of a pain in the
butt to test in isolation.
Brian Pontarelli wrote:
>
>
> We could do that if you like. Those are pretty simple numbers with
> very straight-forward cases. So, please run those against MVEL and let
> me know what you get. StringTokenizer is obviously quite fast, and I
> could easily remove it if it would mean sub-millisecond times,
> although the work probably isn't worth the effort with such small
> numbers.
>
> Just create three classes:
>
> An action
> A user object
> An address object
>
> The action has a user and the user has a generic Map of addresses
> keyed off a String. This should work:
>
> public class Action
>public User user;
> }
>
> public class User {
>public int age;
>public Map addresses;
> }
>
> public class Address {
>public String zipcode;
> }
>
> Then, just get and set some values without any pre-compile or caching
> and let me know what the times are. My guess is that you will be
> slightly slower or the same. To get truly accurate, we might have to
> go sub-millisecond or create some more dramatic tests.
>
> Also, I doubt that StringTokenizer is impacting my performance any. In
> fact the numbers clearly state otherwise. Besides, with things
> happening sub-millisecond or just above that, I just don't see any
> benefit in spending a lot of time making it faster.
>
> -bp
>
>
>
> On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
>
>>
>> Well, I'd like to see an actual comparison. I somehow doubt your
>> parser,
>> which I note is using StringTokenizer will perform as well as MVEL's
>> parser,
>> which is a much more computationally efficient sliding-window parser.
>>
>>
>> Brian Pontarelli wrote:
>>>
>>> Right, but you can receive similar or better performance using a
>>> linear runtime evaluation if the language is simple enough and tuned
>>> for the web. And as you and I say, MVEL and most other languages
>>> aren't targeted to the web and have many extra features.
>>>
>>> I can't really believe that JUEL is that slow though. And if it
>>> really
>>> is, it should be extremely simple to make it just as fast as MVEL.
>>> But
>>> I couldn't say for certain because I don't know the code.
>>>
>>> I ran some simple tests on getting and setting properties for the
>>> JCatapult expression evaluator and here's what I got:
>>>
>>> Retrieving from a JavaBean property ("user.age") 1ms
>>> Retrieving from a public member field ("user.age") < 1ms
>>> Retrieving from a nested JavaBean property within a collection
>>> ("user.addresses['home'].zipcode") 1ms
>>> Retrieving from a nested public member field within a collection
>>> ("user.addresses['home'].zipcode") 1ms
>>>
>>> Setting a JavaBean property with type conversion ("user.age") 1ms
>>> Setting a nested JavaBean property, with collections and Object
>>> creation ("user.addresses['home'].zipcode") 2ms
>>>
>>> That's definitely fast enough for my web applications. ;)
>>>
>>> JCatapult does support using public member fields of classes and it
>>> does shave a little bit of time, but nothing that would make a huge
>>> difference. These are all runtime parsing and handling, nothing is
>>> compiled or cached.
>>>
>>> -bp
>>>
>>> On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
>>>
>>>>
>>>> The singleton pattern is used in MVEL, with knowledge of the
>>>> tradeoff. MVEL
>>>> has a strong emphasis on maintaining interpreted-mode performance.
>>>>
>>>> MVEL contains two runtime systems: an interpreter, and a compiler/
>>>> runtime.
>>>> Unlike other ELs, MVEL does not simply bootstrap the compiler, and
>>>> execute
>>>> that way. Instead, MVEL has a real-time interpreter which evaluates
>>>> to a
>>>> st
Re: MVEL?
Well, I'd like to see an actual comparison. I somehow doubt your parser,
which I note is using StringTokenizer will perform as well as MVEL's parser,
which is a much more computationally efficient sliding-window parser.
Brian Pontarelli wrote:
>
> Right, but you can receive similar or better performance using a
> linear runtime evaluation if the language is simple enough and tuned
> for the web. And as you and I say, MVEL and most other languages
> aren't targeted to the web and have many extra features.
>
> I can't really believe that JUEL is that slow though. And if it really
> is, it should be extremely simple to make it just as fast as MVEL. But
> I couldn't say for certain because I don't know the code.
>
> I ran some simple tests on getting and setting properties for the
> JCatapult expression evaluator and here's what I got:
>
> Retrieving from a JavaBean property ("user.age") 1ms
> Retrieving from a public member field ("user.age") < 1ms
> Retrieving from a nested JavaBean property within a collection
> ("user.addresses['home'].zipcode") 1ms
> Retrieving from a nested public member field within a collection
> ("user.addresses['home'].zipcode") 1ms
>
> Setting a JavaBean property with type conversion ("user.age") 1ms
> Setting a nested JavaBean property, with collections and Object
> creation ("user.addresses['home'].zipcode") 2ms
>
> That's definitely fast enough for my web applications. ;)
>
> JCatapult does support using public member fields of classes and it
> does shave a little bit of time, but nothing that would make a huge
> difference. These are all runtime parsing and handling, nothing is
> compiled or cached.
>
> -bp
>
> On Oct 11, 2008, at 3:09 PM, Chris Brock wrote:
>
>>
>> The singleton pattern is used in MVEL, with knowledge of the
>> tradeoff. MVEL
>> has a strong emphasis on maintaining interpreted-mode performance.
>>
>> MVEL contains two runtime systems: an interpreter, and a compiler/
>> runtime.
>> Unlike other ELs, MVEL does not simply bootstrap the compiler, and
>> execute
>> that way. Instead, MVEL has a real-time interpreter which evaluates
>> to a
>> stack during parsing. Therefore, the general design decisions,
>> particularly
>> around extendability tend to favor singleton-patterns, instead of
>> heavyweight configuration sessions which would completely bog down the
>> performance.
>>
>> http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html
>>
>> For an example of how performant MVEL's interpreter is with no factory
>> caching.
>>
>> In a simple property expression, with no caching (so parsing before
>> executing every time), MVEL was able to parse/reduce the expression
>> "foo.bar" 100,000 times in 94ms. It took JUEL 2749ms to do the same.
>>
>> Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too.
>>
>> So I would err on the side of performance here. If that doesn't cut
>> it for
>> web applications, I guess that's fine. I don't really target MVEL
>> towards
>> web applications, really.
>>
>>
>>
>> Brian Pontarelli wrote:
>>>
>>> Taking a brief look at the MVEL type conversion API it could be
>>> somewhat difficult to get this information into the converter on a
>>> per
>>> request basis, especially if converters are singleton scoped. This
>>> information isn't available on the source in most cases. It is
>>> usually
>>> externalized in the request or the container object. The API looks a
>>> pretty lightweight, which is nice, but also restrictive. From what I
>>> could see I would have to monkey around with things and use something
>>> like a ThreadLocal to pass this information to the converter.
>>>
>>> The source-from-many pattern seems to be somewhat backwards for the
>>> web. It is more likely the case that a single converter will convert
>>> to many classes from a String or String[]. The JCatapult type
>>> converter passes in the type being converted to and then the String
>>> value(s). Although this is very web centric, it cleans up the API and
>>> makes things simpler to implement. MVEL is obviously more generic,
>>> which means some massaging is necessary to tune it for the web.
>>>
>>> It also seems to be lacking a good set of exceptions thrown out of
>>> the
>>> API. At least f
Re: MVEL?
Here is the documentation for type converters in MVEL: http://docs.codehaus.org/display/MVEL/Type+Converters Brian Pontarelli wrote: > > Taking a brief look at the MVEL type conversion API it could be > somewhat difficult to get this information into the converter on a per > request basis, especially if converters are singleton scoped. This > information isn't available on the source in most cases. It is usually > externalized in the request or the container object. The API looks a > pretty lightweight, which is nice, but also restrictive. From what I > could see I would have to monkey around with things and use something > like a ThreadLocal to pass this information to the converter. > > The source-from-many pattern seems to be somewhat backwards for the > web. It is more likely the case that a single converter will convert > to many classes from a String or String[]. The JCatapult type > converter passes in the type being converted to and then the String > value(s). Although this is very web centric, it cleans up the API and > makes things simpler to implement. MVEL is obviously more generic, > which means some massaging is necessary to tune it for the web. > > It also seems to be lacking a good set of exceptions thrown out of the > API. At least from the docs, since I couldn't find JavaDoc and the > distribution only has source (ouch). This doesn't mean that Struts > can't provide good runtime exceptions and then just catch those, but > it leaves things much more open for developers writing new converters. > I'd rather see the API define these exceptions clearly and for them to > be checked. > > I think that using generic languages like OGNL or MVEL are decent > solutions, but a web centric solution would be best. I'm also in favor > or dropping most if not all of the extra features and only providing > property/field getting and setting. I think adding in another language > just clouds the waters. FreeMarker and JSP both have languages that > cover most of the common cases. > > Feel free to take a look at the JCatapult MVC expression evaluator for > what I feel should be supported. > > -bp > > > On Oct 11, 2008, at 12:52 PM, Chris Brock wrote: > >> >> MVEL has a pluggable type-conversion API, just like OGNL. Since it's >> source-from-many in it's design, you can easily design converters that >> perform as much introspection as necessary to determine formatting, >> etc. >> >> >> >> Brian Pontarelli wrote: >>> >>> Yeah. That's good. The last thing I would toss in as criteria is a >>> good type conversion interface. In JCatapult, I actually took >>> things a >>> step further. I found that complex types usually needed more >>> information than just the data to perform the type conversion. For >>> example, conversion of dates generally requires the date format. >>> Likewise, conversion to money generally requires the currency code. >>> In >>> many MVCs this information is statically configured for the entire >>> application, configured per action in XML or properties files or >>> fixed >>> and not configurable at all. >>> >>> For maximum flexibility, I built a system where tags could provide >>> this additional data via extra attributes (it can also be configured >>> application wide as well). My tags look like this: >>> >>> [EMAIL PROTECTED] name="user.lifeSavings" currencyCode="USD"/] >>> [EMAIL PROTECTED] name="user.birthDay" dateTimeFormat="MM/dd/"/] >>> >>> This information then gets passed to the type converters as part of >>> the API. >>> >>> This then reveals another shortcoming of OGNL and the wrapper in >>> Struts, what if a required attribute is missing? This is a different >>> case then if the type conversion fails. So, I created two distinct >>> checked exceptions to handle these two cases. This makes the type >>> conversion system more powerful and easy to interact with. Plus, it >>> reveals good exceptions for coding problems. >>> >>> -bp >>> >>> On Oct 10, 2008, at 3:00 AM, Chris Brock wrote: >>> >>>> >>>> MVEL will handle type coercion for method parameters, properties, >>>> and even on >>>> egress of those values if the generic type information can be >>>> deduced on >>>> ingress. In situtations where the generic type is dependent on the >>>> root of >>>&g
Re: MVEL?
The singleton pattern is used in MVEL, with knowledge of the tradeoff. MVEL has a strong emphasis on maintaining interpreted-mode performance. MVEL contains two runtime systems: an interpreter, and a compiler/runtime. Unlike other ELs, MVEL does not simply bootstrap the compiler, and execute that way. Instead, MVEL has a real-time interpreter which evaluates to a stack during parsing. Therefore, the general design decisions, particularly around extendability tend to favor singleton-patterns, instead of heavyweight configuration sessions which would completely bog down the performance. http://artexpressive.blogspot.com/2007/11/juel-vs-mvel.html For an example of how performant MVEL's interpreter is with no factory caching. In a simple property expression, with no caching (so parsing before executing every time), MVEL was able to parse/reduce the expression "foo.bar" 100,000 times in 94ms. It took JUEL 2749ms to do the same. Compiled performance was: 5.8ms to 34.2ms in favor of MVEL too. So I would err on the side of performance here. If that doesn't cut it for web applications, I guess that's fine. I don't really target MVEL towards web applications, really. Brian Pontarelli wrote: > > Taking a brief look at the MVEL type conversion API it could be > somewhat difficult to get this information into the converter on a per > request basis, especially if converters are singleton scoped. This > information isn't available on the source in most cases. It is usually > externalized in the request or the container object. The API looks a > pretty lightweight, which is nice, but also restrictive. From what I > could see I would have to monkey around with things and use something > like a ThreadLocal to pass this information to the converter. > > The source-from-many pattern seems to be somewhat backwards for the > web. It is more likely the case that a single converter will convert > to many classes from a String or String[]. The JCatapult type > converter passes in the type being converted to and then the String > value(s). Although this is very web centric, it cleans up the API and > makes things simpler to implement. MVEL is obviously more generic, > which means some massaging is necessary to tune it for the web. > > It also seems to be lacking a good set of exceptions thrown out of the > API. At least from the docs, since I couldn't find JavaDoc and the > distribution only has source (ouch). This doesn't mean that Struts > can't provide good runtime exceptions and then just catch those, but > it leaves things much more open for developers writing new converters. > I'd rather see the API define these exceptions clearly and for them to > be checked. > > I think that using generic languages like OGNL or MVEL are decent > solutions, but a web centric solution would be best. I'm also in favor > or dropping most if not all of the extra features and only providing > property/field getting and setting. I think adding in another language > just clouds the waters. FreeMarker and JSP both have languages that > cover most of the common cases. > > Feel free to take a look at the JCatapult MVC expression evaluator for > what I feel should be supported. > > -bp > > > On Oct 11, 2008, at 12:52 PM, Chris Brock wrote: > >> >> MVEL has a pluggable type-conversion API, just like OGNL. Since it's >> source-from-many in it's design, you can easily design converters that >> perform as much introspection as necessary to determine formatting, >> etc. >> >> >> >> Brian Pontarelli wrote: >>> >>> Yeah. That's good. The last thing I would toss in as criteria is a >>> good type conversion interface. In JCatapult, I actually took >>> things a >>> step further. I found that complex types usually needed more >>> information than just the data to perform the type conversion. For >>> example, conversion of dates generally requires the date format. >>> Likewise, conversion to money generally requires the currency code. >>> In >>> many MVCs this information is statically configured for the entire >>> application, configured per action in XML or properties files or >>> fixed >>> and not configurable at all. >>> >>> For maximum flexibility, I built a system where tags could provide >>> this additional data via extra attributes (it can also be configured >>> application wide as well). My tags look like this: >>> >>> [EMAIL PROTECTED] name="user.lifeSavings" currencyCode="USD"/] >>> [EMAIL PROTECTED] name="user.birthD
Re: MVEL?
MVEL has a pluggable type-conversion API, just like OGNL. Since it's
source-from-many in it's design, you can easily design converters that
perform as much introspection as necessary to determine formatting, etc.
Brian Pontarelli wrote:
>
> Yeah. That's good. The last thing I would toss in as criteria is a
> good type conversion interface. In JCatapult, I actually took things a
> step further. I found that complex types usually needed more
> information than just the data to perform the type conversion. For
> example, conversion of dates generally requires the date format.
> Likewise, conversion to money generally requires the currency code. In
> many MVCs this information is statically configured for the entire
> application, configured per action in XML or properties files or fixed
> and not configurable at all.
>
> For maximum flexibility, I built a system where tags could provide
> this additional data via extra attributes (it can also be configured
> application wide as well). My tags look like this:
>
> [EMAIL PROTECTED] name="user.lifeSavings" currencyCode="USD"/]
> [EMAIL PROTECTED] name="user.birthDay" dateTimeFormat="MM/dd/"/]
>
> This information then gets passed to the type converters as part of
> the API.
>
> This then reveals another shortcoming of OGNL and the wrapper in
> Struts, what if a required attribute is missing? This is a different
> case then if the type conversion fails. So, I created two distinct
> checked exceptions to handle these two cases. This makes the type
> conversion system more powerful and easy to interact with. Plus, it
> reveals good exceptions for coding problems.
>
> -bp
>
> On Oct 10, 2008, at 3:00 AM, Chris Brock wrote:
>
>>
>> MVEL will handle type coercion for method parameters, properties,
>> and even on
>> egress of those values if the generic type information can be
>> deduced on
>> ingress. In situtations where the generic type is dependent on the
>> root of
>> the object graph though, MVEL cannot infer generic type data (ie. a
>> bound
>> variable, that's say a Map) because of erasure. There is no generic
>> type
>> information held on a per-instance basis.
>>
>> However, if the parameterized type is a class member say:
>>
>> class Foo {
>> public Map map;
>> }
>>
>> And you use an instance of Foo as a context or as a bound variable,
>> MVEL's
>> compiler can certainly extract the generic type information, and
>> provide
>> automatic coercion and verification accordingly. MVEL's type
>> verifier will
>> always extrapolate whatever type data is available.
>>
>>
>>
>> Brian Pontarelli wrote:
>>>
>>> This is not quite the same unless it can detect generics while
>>> setting
>>> values and creating values. An example might be values from a form
>>> going into something like:
>>>
>>> List
>>>
>>> or
>>>
>>> Map>
>>>
>>> or the always fun
>>>
>>> List>
>>>
>>> that sorta thing. I know that OGNL had (might not any longer) many
>>> issues with generics in this respect. I think OGNL also got mad when
>>> it encountered something simple like:
>>>
>>> int[]
>>>
>>> or
>>>
>>> String[]
>>>
>>> coming from checkbox lists and multiple selects. I believe that it
>>> would stuff the values into the String[] like this:
>>>
>>> {"value1,value2,value3"}
>>>
>>> rather than
>>>
>>> {"value1", "value2", "value3"}
>>>
>>> This was a while ago, so all of this might be fixed.
>>>
>>> -bp
>>>
>>>
>>> On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
>>>
>>>>
>>>> MVEL 2.0 has full support for generics (and static typing):
>>>> http://mvel.codehaus.org/Strong+Typing+Mode
>>>>
>>>>
>>>> Brian Pontarelli wrote:
>>>>>
>>>>>
>>>>> On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
>>>>>
>>>>>> Just to muddy the EL/templating waters:
>>>>>>
>>>>>> http://mvel.codehaus.org/Performance+of+MVEL
>>>>>>
>>>>>> (v. OGNL)
>>>>>
>>>>> Not sure about MVEL or OGNL at this point, but everything
Re: MVEL?
MVEL will handle type coercion for method parameters, properties, and even on
egress of those values if the generic type information can be deduced on
ingress. In situtations where the generic type is dependent on the root of
the object graph though, MVEL cannot infer generic type data (ie. a bound
variable, that's say a Map) because of erasure. There is no generic type
information held on a per-instance basis.
However, if the parameterized type is a class member say:
class Foo {
public Map map;
}
And you use an instance of Foo as a context or as a bound variable, MVEL's
compiler can certainly extract the generic type information, and provide
automatic coercion and verification accordingly. MVEL's type verifier will
always extrapolate whatever type data is available.
Brian Pontarelli wrote:
>
> This is not quite the same unless it can detect generics while setting
> values and creating values. An example might be values from a form
> going into something like:
>
> List
>
> or
>
> Map>
>
> or the always fun
>
> List>
>
> that sorta thing. I know that OGNL had (might not any longer) many
> issues with generics in this respect. I think OGNL also got mad when
> it encountered something simple like:
>
> int[]
>
> or
>
> String[]
>
> coming from checkbox lists and multiple selects. I believe that it
> would stuff the values into the String[] like this:
>
> {"value1,value2,value3"}
>
> rather than
>
> {"value1", "value2", "value3"}
>
> This was a while ago, so all of this might be fixed.
>
> -bp
>
>
> On Oct 9, 2008, at 7:32 PM, Chris Brock wrote:
>
>>
>> MVEL 2.0 has full support for generics (and static typing):
>> http://mvel.codehaus.org/Strong+Typing+Mode
>>
>>
>> Brian Pontarelli wrote:
>>>
>>>
>>> On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
>>>
>>>> Just to muddy the EL/templating waters:
>>>>
>>>> http://mvel.codehaus.org/Performance+of+MVEL
>>>>
>>>> (v. OGNL)
>>>
>>> Not sure about MVEL or OGNL at this point, but everything was lacking
>>> in support for generics, collections and arrays. I wrote my own for
>>> the JCatapult MVC and it was really not all that hard. It only
>>> handles
>>> getting and setting, but I figure that's all that should be allowed
>>> at
>>> that point anyways.
>>>
>>> -bp
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/MVEL--tp19867360p19910418.html
>> Sent from the Struts - Dev mailing list archive at Nabble.com.
>>
>>
>> -
>> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19914597.html
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: MVEL?
MVEL 2.0 has full support for generics (and static typing): http://mvel.codehaus.org/Strong+Typing+Mode Brian Pontarelli wrote: > > > On Oct 7, 2008, at 3:08 PM, Dave Newton wrote: > >> Just to muddy the EL/templating waters: >> >> http://mvel.codehaus.org/Performance+of+MVEL >> >> (v. OGNL) > > Not sure about MVEL or OGNL at this point, but everything was lacking > in support for generics, collections and arrays. I wrote my own for > the JCatapult MVC and it was really not all that hard. It only handles > getting and setting, but I figure that's all that should be allowed at > that point anyways. > > -bp > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/MVEL--tp19867360p19910418.html 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: [s2] extras-lib (was JUEL plugin (was Roadmap for the core taglib))
For the record, I still maintain that it's better :) Tom Schneider wrote: > > Putting down my work would only motivate me more. :) That's exactly > how this was started back in February--Chris Brock was bragging about > how superior MVEL was and how slow OGNL was. Well, we'll show him! > Tom > > On 11/7/07, Ian Roughley <[EMAIL PROTECTED]> wrote: >> It's great that Tom is doing this work, and it wasn't my intent to put >> down the effort. I guess I was just trying to preempt given some of the >> OGNL threads. >> >> /Ian >> >> Tom Schneider wrote: >> > LOL, I didn't know my efforts were going to cause such a raucous. :) >> > >> > Ted is correct--I started this on Saturday on a whim. At this point >> > it is completely experimental--we have a long ways to go before it is >> > even close to usable. However, I was able to execute a simple >> > expression using my value stack, which for me, was a worthwhile >> > accomplishment. I didn't want Don's work to abstract away the value >> > stack to be completely wasted, we needed at least one other value >> > stack implementation to truly test his changes. Don did good work, >> > but there is still a lot of OGNLisms that have crept into the code >> > over time. It would be nice to find and eliminate these >> > >> > Ian brings up a good point in that we'll have to decide how to handle >> > some things like I18N/type conversion/method invocation. Not all EL's >> > are created equal and OGNL probably is a little more flexible and >> > powerful than most. Then even if we get all that working, what's the >> > migration strategy? >> > Tom >> > >> >> - >> 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] > > > -- View this message in context: http://www.nabble.com/-s2--extras-lib-%28was-JUEL-plugin-%28was-Roadmap-for-the-core-taglib%29%29-tf4751589.html#a13635524 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
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 w
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 text
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: >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> name="nestedBean.attribute1"/> >>> > >> name="nestedBean.attribute2"/> >>> > >> name="nestedBean.attribute3"/> >>> > >> name="nestedBean.attribute4"/> >>> > >> name="nestedBean.attribute5"/> >>> > >> name="nestedBean.attribute6"/> >>> > >> name="nestedBean.attribute7"/> >>> > >> name="nestedBean.attribute8"/> >>> > >> name="nestedBean.attribute9"/> >>> > >>> > >>> > >>> > >>> > >>> > 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 >>> >
