First public beta of MVEL 2.0, I mean :)
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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > -- View this message in context: http://www.nabble.com/MVEL--tp19867360p19948124.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]
