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]
