Bug 1276311

Summary:	Buildtime performance degradation in BR engine when building KieBase from dtables
Product:	[Retired] JBoss BRMS Platform 6	Reporter:	Tibor Zimanyi <tzimanyi>
Component:	BRE	Assignee:	Mario Fusco <mfusco>
Status:	CLOSED EOL	QA Contact:	Tibor Zimanyi <tzimanyi>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.2.0	CC:	kverlaen, rrajasek
Target Milestone:	CR1
Target Release:	6.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-27 19:09:27 UTC	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:

Comment 1 Mario Fusco 2015-10-30 09:12:21 UTC

The perceived performance degradation has been in reality caused by this fix https://github.com/droolsjbpm/drools/commit/dc81e1f1ca7f56a29b4fb6c0ad0e14bb3c49551c

Now when the compiler finds a complex constraint like the following (that is produced by one of the decision table in the benchmark) 

"X".equals("MASTER") && "X".equals(qualifier) || "X".equals("CATCHALL") && qualifier.equals( "X") && catalogProductModel.getPchId() == null || qualifier.equals("X") && "X".equals("X")

it correctly analyses and eventually normalizes all the subexpressions in that constraint, something that didn't do at all before. 

I tried to mitigate the performance impact of this further necessary checks with this commit https://github.com/droolsjbpm/drools/commit/0b935033f

I checked the effects of this last commit running the Walmart dtable 100 benchmark on my machine with the following results:

before the fix for BZ-1253575
693.183 ± 5.010  ms/op

after the fix but before this performance optimization
809.843 ± 2.854  ms/op

after the performance optimization
779.763 ± 5.744  ms/op

Comment 2 Mario Fusco 2015-11-05 13:41:41 UTC

I also cherry-picked to 6.3.x this fix https://github.com/droolsjbpm/drools/commit/cc9a5eab6dc5e6e2a06ace59a3d0c8e0ce282b59 because investigating the issue reported in https://issues.jboss.org/browse/DROOLS-970 I've also found a way to further optimize the performances of the PatterBuilder. 

After this fix I rerun the benchmark mentioned in the former comment obtaining the following result:

747.449 ± 3.265 ms/op

Comment 3 Tibor Zimanyi 2015-11-25 09:47:02 UTC

Verified in 6.2.0.CR1. There are improvements from 7% to 10 % against ER5 in dtables benchmarks that we have. I will publish CR1 performance report soon.