For those interested in the MVEL integration, I uploaded what I have so far to:
http://svn.opensymphony.com/svn/xwork/branches/xwork-mvel/
There is plenty of stuff to be done, bot some nice things like the
magic population of lists, employee[1].name = el zorro are working.
and a MVELValueStack
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
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
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
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
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
-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
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
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
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
()-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
);
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
);
}
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
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
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
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
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
.
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
I'll send you my unit test that does it on my box directly.
-bp
On Oct 12, 2008, at 8:34 PM, 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
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
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
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
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
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
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
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
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
[] 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
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
I've actually been working on the mvel integration since last week to
see if it is doable and to check if the performance win is indeed as
significant as we all hope. So far, (most of) the valuestack and
ognlutil have been successfully replaced, but I've only focused on XW
at this time. I hope
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v. OGNL)
Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'm not sure that this muddies things much - MVEL has come up before:
http://struts.markmail.org/search/?q=MVEL
--
Martin Cooper
On Tue, Oct 7, 2008 at 2:08 PM, Dave Newton [EMAIL PROTECTED] wrote:
Just to muddy the EL/templating waters:
http://mvel.codehaus.org/Performance+of+MVEL
(v
Touché¹.
_
¹ Threeché even.
--
From: Martin Cooper [EMAIL PROTECTED]
Sent: Tuesday, October 07, 2008 5:15 PM
To: Struts Developers List dev@struts.apache.org;
[EMAIL PROTECTED]
Subject: Re: MVEL?
I'm not sure that this muddies
33 matches
Mail list logo
