struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <>
Subject Re: MVEL?
Date Mon, 13 Oct 2008 02:30:07 GMT
> 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  

> Take these real benchmarks (from MVEL 1.2--which is old):
> Test Name            : Deep Property
> Expression           :
> Iterations           : 50000
> 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  

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  

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 be difficult to swap in MVEL without some tweaks to the type  
conversion API. But I could look into it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message