struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: MVEL?
Date Mon, 13 Oct 2008 03:07:18 GMT
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 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. "
>
> This is the first public beta of MVEL.  Much of the code has not been
> publicly flushed out.  So we do expect bugs.  But I'd be particularly
> interested in trying to recreate the conditions of this.
>
>
> Brian Pontarelli wrote:
>>
>>> 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
>> linear.
>>
>>
>>>
>>> Take these real benchmarks (from MVEL 1.2--which is old):
>>>
>>> Test Name            : Deep Property
>>> Expression           : foo.bar.name
>>> 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
>> side:
>>
>> 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
>> roughly:
>>
>> 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.
>>
>>
>> -bp
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
> -- 
> View this message in context: http://www.nabble.com/MVEL--tp19867360p19948081.html
> Sent from the Struts - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message