#x27;t divided into its pieces but rather
> evaluated character by character until a boundary is hit, at which
> time that portion is evaluated? I wouldn't think this would increase
> performance drastically, but you would know much better than I.
>
>
>
> On
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
" 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
ndling 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 i = 0; i &l
(s, entityObj);
}
System.out.println("compiled time: " + (System.currentTimeMillis()-start));
Brian Pontarelli wrote:
>
>
> 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
ator.getValue("user.addresses['home'].zipcode",
> action);
> }
> end = System.currentTimeMillis();
> System.out.println("50 times was " + (end - start));
> }
>
> And the output:
>
> [junit] S
ise. Besides, with things
> happening sub-millisecond or just above that, I just don't see any
> benefit in spending a lot of time making it faster.
>
> -bp
>
>
>
> On Oct 12, 2008, at 11:46 AM, Chris Brock wrote:
>
>>
>> Well, I'd like to se
collections and Object
> creation ("user.addresses['home'].zipcode") 2ms
>
> That's definitely fast enough for my web applications. ;)
>
> JCatapult does support using public member fields of classes and it
> does shave a little bit of time, but noth
s the waters. FreeMarker and JSP both have languages that
> cover most of the common cases.
>
> Feel free to take a look at the JCatapult MVC expression evaluator for
> what I feel should be supported.
>
> -bp
>
>
> On Oct 11, 2008, at 12:52 PM, Chris Brock wrot
mon cases.
>
> Feel free to take a look at the JCatapult MVC expression evaluator for
> what I feel should be supported.
>
> -bp
>
>
> On Oct 11, 2008, at 12:52 PM, Chris Brock wrote:
>
>>
>> MVEL has a pluggable type-conversion API, just like OGNL. Since
attribute is missing? This is a different
> case then if the type conversion fails. So, I created two distinct
> checked exceptions to handle these two cases. This makes the type
> conversion system more powerful and easy to interact with. Plus, it
> reveals good exceptio
uld stuff the values into the String[] like this:
>
> {"value1,value2,value3"}
>
> rather than
>
> {"value1", "value2", "value3"}
>
> This was a while ago, so all of this might be fixed.
>
> -bp
>
>
> On Oct
MVEL 2.0 has full support for generics (and static typing):
http://mvel.codehaus.org/Strong+Typing+Mode
Brian Pontarelli wrote:
>
>
> On Oct 7, 2008, at 3:08 PM, Dave Newton wrote:
>
>> Just to muddy the EL/templating waters:
>>
>> http://mvel.codehaus.org/Performance+of+MVEL
>>
>> (v. OGNL)
For the record, I still maintain that it's better :)
Tom Schneider wrote:
>
> Putting down my work would only motivate me more. :) That's exactly
> how this was started back in February--Chris Brock was bragging about
> how superior MVEL was and how slow OGNL was. Well,
ke that happen, I would consider it my early
> Christmas present :)
>
> Don
>
> Chris Brock wrote:
>> Why do you think it would be so terribly difficult? What does MVEL not
>> support that is currently supported by OGNL that would not be fixable by
>> a
>>
d to see it. :)
>
> Don
>
> Chris Brock wrote:
>> I think the problem is that the Tapestry solution is simply a property
>> accessor package, which doesn't really meet the needs of the established
>> WebWork community which relies on "expressions" in additi
I think the problem is that the Tapestry solution is simply a property
accessor package, which doesn't really meet the needs of the established
WebWork community which relies on "expressions" in addition to properties to
accomplish tasks.
That being said, my project (MVEL) stands willing to step
18 matches
Mail list logo
