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 JexlArithmetic as
is:
{code}
public static class JMeterArithmetic extends JexlArithmetic {
public JMeterArithmetic(boolean astrict) {
super(astrict);
}
/**
* A workaround to create an operator overload
* @param jma an improbable parameter class
* @return 1
*/
public int size(JMeterArithmetic jma) {
return 1;
}
}
{code}
And use it at engine creation time:
{code}
JexlEngine jexl = new JexlBuilder()
.cache(512)
.silent(true)
.strict(true)
.arithmetic(new JMeterArithmetic(true))
.create();
{code}
Let us know how it goes (if/when you find the time).
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/JEXL3-Performance-degradation-compared-to-2-1-1-tp4682086p4682110.html
Sent from the Commons - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
