Bug 976824 - Possible performance regression (5.3.1-P02 vs P03)
Possible performance regression (5.3.1-P02 vs P03)
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion) (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mario Fusco
Lukáš Petrovický
Depends On:
Blocks: 979436
  Show dependency treegraph
Reported: 2013-06-21 10:51 EDT by Petr Široký
Modified: 2015-02-24 13:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple Maven based reproducer (13.54 KB, application/zip)
2013-06-21 10:54 EDT, Petr Široký
no flags Details

  None (edit)
Description Petr Široký 2013-06-21 10:51:15 EDT
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):

How reproducible:

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.
Comment 1 Petr Široký 2013-06-21 10:54:34 EDT
Created attachment 763875 [details]
Simple Maven based reproducer
Comment 2 Petr Široký 2013-06-24 05:22:32 EDT
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.


The commit is fixing JBRULES-3274, so we probably can't just exclude it.
Comment 3 Mario Fusco 2013-06-25 10:07:55 EDT
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


and the provided test case showed a quite satisfying performance improvement.

Note You need to log in before you can comment on or make changes to this bug.