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, Debugging it, it is not called.
Regards On Friday, January 22, 2016, henrib <[email protected]> wrote: > 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] <javascript:;> > For additional commands, e-mail: [email protected] > <javascript:;> > > -- Cordialement. Philippe Mouawad.
