Discussions

News: MVEL 1.0, MVFLEX Expression Language, released

  1. The MVFLEX/Valhalla project is pleased to announce the release of its premier expression language, MVEL, for general consumption by the Java community at large. MVEL is a property extraction and expression language for use in everything from frameworks to creating extensible configuration facilities. It was created out of a general dissatisfaction with the performance and stagnation of OGNL. The design philosophy of MVEL is somewhat different from other offerings, in that I decided to go with a much simpler parsing algorithm that others. MVEL does not use an AST parser, or a complex pre-compiler. It parses/interprets on the fly and does it faster than others. MVEL is an LALR parser utilizing a reduce-fast stack algorithm. And at over 1700% faster than OGNL in most applications, we think you’ll agree that simpler is better. MVEL also features many interesting language features that I think you’ll find useful, such as a universal "contains" operator that lets you check whether or not a value is contained within a String, Map, Collection, or Array. Or the "Chained-Or" operator that returns the first non-null value in the chain. You can find out more about these features and the rest of MVEL at our WikiSite.

    Threaded Messages (7)

  2. not to troll, but the performance examples should be wrapped in "@{" + str + "}" to actually evaluate the results. From comparing to the new EL-api: RESULTS: test.fubar != null mvnObj = true elObj = true mvn ms = 0.0125 el ms = 0.00297 RESULTS: test.num + 10 - 1 mvnObj = 19 elObj = 19 mvn ms = 0.0181 el ms = 0.00393 This was 100,000 iterations, average execution time. One thing this little test did show was that it's a lot of leg work to build up the API components to even do the evaluation, which possibly means a simple wrapper would need to be provided to get the same ease of OGNL or MVEL or BeanShell.
  3. btw, the new EL-API I'm referring to is part of the JEE 5 container and used within JSP 2.1, JSF 1.2, and hopefully other frameworks in the future.
  4. Lastly, from my own tests against OGNL, OGNL.getValue(..) doesn't cache it's parsed representation. Caching the parsed node tree shows that OGNL is actually quite a bit faster than MVEL and comparable to EL in a single thread test.
  5. Sure, caching is faster.[ Go to top ]

    And MVEL will support similar caching of the compiled execution stack. But that's really a moot point. In many implementations it's not practical to cache every EL statement, especially in web applications. A single web page, may have 50 or more expressions on it, many of them dynamic. And if it's a large program, caching every statement into a large hash table could lead to memory leaks (especially if those expressions are constructed dynamically in a loop) We're comparing uncompiled/uncached MVEL to uncompled/uncached OGNL. That's not an unfair comparison.
  6. Re: Sure, caching is faster.[ Go to top ]

    We're comparing uncompiled/uncached MVEL to uncompled/uncached OGNL. That's not an unfair comparison.
    Sure, but you're the one that said MVEL was 1700% faster than OGNL-- just trying to test the facts here :-)
  7. Some performance drawbacks.[ Go to top ]

    However, MVEL suffers from some unavoidable performance drawbacks as part of a performance-extensibility trade off. For example, MVEL supports transient variable assignment, and also variable injection in addition to having root contexts. If you neuter some of these capabilities, then MVEL's performance increases significantly over it's current level. Not to mention that there are certain language extensions supported in MVEL, not supported in other EL's. The other thing to consider is that MVEL 1.0 does not currently support any type of caching on repetitive statements, so each statement is re-compiled and executed on each iteration of the test. This should at least speak to how efficiently it accomplishes this. I'm considering putting a caching wrapper around the main parser-interpreter to cache the compiled execution stack to prevent reparse/recompiles of statements in a loop, and that will have dramatic improvement to the loop-test. It will drop the entire overhead to a simple hash lookup and stack traversal on each iteration, which by any informed guestimate would probably drop the current figures to about 20% of their current values in the benchmarks at worst. And MVEL has a templating parser which supports @{expression} like statements. Even when you switch to that parser, it's still no contest. It only adds about 10% overhead. And it isn't silly enough of an implementation to use string-appending to accomplish that. MVEL almost exclusively using array manipulation to do all it's parsing to avoid any costly (and unnecessary) string creation.
  8. Where is mvflex.org?[ Go to top ]

    I have used mvflex early last year, however, its site has been down for months, is there a new site? where is it? this really makes me consider switching back to ognl.