Re: MVEL?

[Brian Pontarelli]

BTW, I've got everything setup for using the 2.0-beta1 JAR file.

-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<String, Address> 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
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.birthDay" dateTimeFormat="MM/dd/yyyy"/]

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<String, Integer> 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<String>

or

        Map<String, List<Integer>>

or the always fun

        List<List<Integer>>

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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
View this message in context:
http://www.nabble.com/MVEL--tp19867360p19935345.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--tp19867360p19936453.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--tp19867360p19943987.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--tp19867360p19947349.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]