Bug 976824

Summary: Possible performance regression (5.3.1-P02 vs P03)
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Petr Široký <psiroky>
Component: BRE (Expert, Fusion)Assignee: Mario Fusco <mfusco>
Status: ASSIGNED --- QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: alazarot, jcoleman, mfusco
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 979436    
Attachments:
Description Flags
Simple Maven based reproducer none

Description Petr Široký 2013-06-21 14:51:15 UTC 
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.
Comment 1 Petr Široký 2013-06-21 14:54:34 UTC 
Created attachment 763875 [details]
Simple Maven based reproducer
Comment 2 Petr Široký 2013-06-24 09:22:32 UTC 
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.
Comment 3 Mario Fusco 2013-06-25 14:07:55 UTC 
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.