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