" 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"
There is no contention in the cache. MVEL returns self-contained, stateless, evaluation trees (or bytecode via the JIT) that do not require synchronization or contention in multi-threaded scenarios. The payload returned by the compiler is essentially stateless code, and there is no "cache" that is used such as reflection cache or otherwise as there is in things like Commons EL, or JEXL. This is actually, from an architectural perspective what makes MVEL stand apart from these technologies. 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--tp19867360p19948098.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]
