Re: JEXL3 Performance degradation compared to 2.1.1

Hi Philippe; I think it's ok to leave the default as debug(true) since it is easy (and often necessary) to create a 'custom' JEXL instance be it for contexts, namespaces and/or arithmetic. It is convenient to provide JexlInfo instances when creating scripts to track potential errors; in that

Re: JEXL3 Performance degradation compared to 2.1.1

Hi Henri, I attached a simple Main class to : https://issues.apache.org/jira/browse/JEXL-186 and the results. Regards Philippe On Fri, Jan 22, 2016 at 8:19 PM, henrib wrote: > Hi; > Since performance is the same with the workaround, we've got > another/different performance

Re: JEXL3 Performance degradation compared to 2.1.1

Hi Philippe; Default debug mode in JEXL3 seems like the other big slowdown cause. Check JEXL-186 for an updated engine startup sequence :-). Cheers, Henrib -- View this message in context:

Re: JEXL3 Performance degradation compared to 2.1.1

Hi Henri, I just answered in JIRA :-) It's now ok with JMeterArithmetic and debug(false) Bug shouldn't debug be false by default ? Second question, what is the impact of keeping JMeterArithmetic ? Or do you plan a new release of commons-jexl3 ? Anyway, thanks for your very fast support ! Great !

Re: JEXL3 Performance degradation compared to 2.1.1

Hi; Since performance is the same with the workaround, we've got another/different performance issue. Is there any easy way to replicate your test - or at least its essence - ? What does your benchmark do ? What are the evaluated expressions / scripts ? Back too your note: the 'size' method is

Re: JEXL3 Performance degradation compared to 2.1.1

Hi, Thanks for the suggestion. I tested it but performance results are the same. Note I don't understand the fix as size method doesn't have this signature in ancestor and I don't understand neither why it would be called in this context, even after changing the signature to match the parent,

Re: JEXL3 Performance degradation compared to 2.1.1

Hi again; It seems you've found a real performance regression. I've been playing some more and it seems the logic around the operator overloading resolution/caching is flawed in the simplest case, i.e. when there is no overload. As a workaround, you may want to try using an overloading

Re: JEXL3 Performance degradation compared to 2.1.1

Hello Philippe;Interesting results indeed.I've been trying to interpret / replicate them but JMeter is a bit too complex for me to understand what the benchmark is achieving and what is measured.Is it 2 loops of an expression that is '3 + 2' ? And the same is performed with 4 threads in

JEXL3 Performance degradation compared to 2.1.1

Hello, I integrated today jexl3 to JMeter trunk: - https://github.com/apache/jmeter/commit/e1bfb7bb01169278d57f4fea7bf0cfaeba44ac50 I made some rapid benchmark using JMeter. My Test plan contains only 1 thread Group with a Debug Sampler as a child: Debug Sampler has Name field set to: