Description of problem: I have a file with simple rules, basically just "=,!=,<,>,||,&&" operators. (Using other operators the regression is still there but not that high). Inserting facts and evaluating the rules (fireAllRules()) takes longer (~20 %) comparing P03 and P02. See the attached Maven reproducer for the rules file and simple test that demonstrates the described behavior. Note: The test is highly synthetic and does not reflect real usage of the rules. However the regression is there. In real scenarios the regression probably will not be that high. Version-Release number of selected component (if applicable): 5.3.1.BRMS-P03 How reproducible: Always Steps to Reproduce: 1. Run the attached test (mvn test) 2. Change the version from 5.3.1.BRMS-P02 to 5.3.1.BRMS-P03 3. Run the test again Actual results: Time needed for execution is higher for P03 (~20 %) Expected results: Both execution times are ~equal.
Created attachment 763875 [details] Simple Maven based reproducer
I have been looking into the issue a little bit and found out that the following commit is probably responsible for the regression. (I have built the drools without that commit and the times is ~same as with P02. http://git.app.eng.bos.redhat.com/?p=droolsjbpm/drools.git;a=commit;h=d4d0aaf8d7749c9ed03f56fe957d3ea496593420 The commit is fixing JBRULES-3274, so we probably can't just exclude it.
The (biggest part of) this performance regression was caused by the internal implementation of the new UpgradableReentrantReadWriteLock. In particular it used 2 maps to hold some necessary counters index by thread (using the thread id as key). I replaced the 2 maps with a ThreadLocal and put the 2 counters there https://github.com/droolsjbpm/drools/commit/8d02abdc0999b60b127ae4b97be94ef20a37d81e#L0L17 and the provided test case showed a quite satisfying performance improvement.