Well, that's one way of implementing a cache. Even if you did do that, the
performance gain from compiling the expression is on the order of a
magnitude (or greater), so any contention in the hash lookup would be far
worth it. However, there are other more efficient strategies that have been
emp
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 s
Not sure I follow. If I compile an expression, how can I reuse the
compiled version? I would assume it would need to be in a cache where
the key is the expression String and the value is the compiled
version. Correct me if I'm wrong.
-bp
P.S. based on your knowledge, I'm wondering if JCata
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
" 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
"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
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 MVE
... I should note that in 2.0b1 the generic type observance is not completely
implemented for set expressions, since we have not augmented the API to
accept a ParserContext object to turn this on (which is required by the
compiler). It is possible to mimic set expressions with the regular
compile
Send me the code to set values which will require object construction
and generic inspection and handling as well.
Thanks,
-bp
On Oct 12, 2008, at 6:35 PM, Chris Brock wrote:
Assuming you're using a context-root, you'd write it like this:
long start = System.currentTimeMillis();
for (int
Assuming you're using a context-root, you'd write it like this:
long start = System.currentTimeMillis();
for (int i = 0; i < iterations; i++ {
MVEL.eval("foo.bar", entityObj); // equivalent of:
entityObj.getFoo().getBar();
}
System.out.println("interpreted time: " +
(System.currentTimeMillis()-
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.
Say you have a page which contains 20 expressions. And your p
BTW, I've got everything setup for using the 2.0-beta1 JAR file.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has dependencies on
HttpServletRequest and
outward dependencies t
Send me code for MVEL and I'll run both. It will be much easier for
you to write good MVEL code than me.
-bp
On Oct 12, 2008, at 6:18 PM, Chris Brock wrote:
I actually tried to do this really quickly earlier. I didn't have
time to
figure it out, as your EL stuff has dependencies on
I actually tried to do this really quickly earlier. I didn't have time to
figure it out, as your EL stuff has dependencies on HttpServletRequest and
outward dependencies to your framework. I tried to check-out everything,
but SVN kept dying while checking out (I think Google's SVN server was
act
Just as a quick update. I realized my tests weren't insulated from
other code running and create a separate unit test to get performance.
The results are now:
Retrieving from a JavaBean property (user.age) 0ms
Retrieving from a field (user.age) 0ms
Retrieving from a Ja
We could do that if you like. Those are pretty simple numbers with
very straight-forward cases. So, please run those against MVEL and let
me know what you get. StringTokenizer is obviously quite fast, and I
could easily remove it if it would mean sub-millisecond times,
although the work p
Well, I'd like to see an actual comparison. I somehow doubt your parser,
which I note is using StringTokenizer will perform as well as MVEL's parser,
which is a much more computationally efficient sliding-window parser.
Brian Pontarelli wrote:
>
> Right, but you can receive similar or better p
Right, but you can receive similar or better performance using a
linear runtime evaluation if the language is simple enough and tuned
for the web. And as you and I say, MVEL and most other languages
aren't targeted to the web and have many extra features.
I can't really believe that JUEL is
ÐÑÐµÐ´Ð»Ð°Ð³Ð°Ñ Ðам наÑÑиÑÑÑÑ Ð·Ð°ÑабаÑÑваÑÑ Ð½Ð°
инÑеÑÐ½ÐµÑ ÑоÑгаÑ
ФоÑекÑ.
ÐÑакÑиковаÑÑÑÑ Ð¼Ð¾Ð¶Ð½Ð¾ на демо или ÑенÑовÑÑ
ÑÑеÑаÑ
, вÑе наглÑдно показано в ÑиÑÑнкаÑ
.
ÐеÑплаÑнÑе кÐ
Europe: I'm in Belgium, Rene and Rainer are in Germany. Antonio
(Italy) is probably the closest. Rene/Rainer: perhaps a combination
with a nice diving vacation ? ;-)
- Phil
On Sun, Oct 12, 2008 at 11:52 AM, Don Brown <[EMAIL PROTECTED]> wrote:
> Any struts devs on that side of the world? I'd lov
Any struts devs on that side of the world? I'd love to go and could
probably get Atlassian to sponsor me, but with the conference on
November 7, it is way too late notice.
Don
On Sat, Oct 11, 2008 at 4:49 AM, Colin Watson
<[EMAIL PROTECTED]> wrote:
> Dear Struts Dev list,
>
> The Open Web Applic
21 matches
Mail list logo
