[
https://issues.apache.org/jira/browse/JEXL-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-186.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: Later)
3.1
The code is corrected in the trunk; there is a workaround in the worst
(immediate) case using a customized JexlArithmetic.
About changing the default creation flags, my experience with integrating JEXL
means tailoring the startup engine sequence anyway. The current default
generates some useful information in case of errors...
> Performance regression in arithmetic operations compared to JEXL 2.1
> --------------------------------------------------------------------
>
> Key: JEXL-186
> URL: https://issues.apache.org/jira/browse/JEXL-186
> Project: Commons JEXL
> Issue Type: Bug
> Affects Versions: 3.0
> Reporter: Philippe Mouawad
> Assignee: Henri Biestro
> Fix For: 3.1
>
> Attachments: PerfJexl2.java, PerfJexl2.java, PerfJexl3.java,
> PerfJexl3.java
>
>
> Compared to JEXL 2.1.1, arithmetic operations are slower in 3.0.
> The culprit is the logic around operators overloading; when the
> JexlArithmetic does not overload any operator, discovering whether it
> overloads one is repeated each time an interpreter is created (which is a
> costly introspection operation).
> As a workaround, one ca use an arithmetic that does overload an operator (for
> instance size) as in:
> {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 an instance of that class at engine creation time as in:
> {code}
> JexlEngine jexl = new JexlBuilder()
> .cache(512)
> .silent(true)
> .strict(true)
> .arithmetic(new JMeterArithmetic(true))
> .create();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
