lucamolteni · February 24, 2020 15:16
diff --git a/gistfile1.txt b/gistfile1.txt
 did you give a try to my fix to index generation? Any feedback?

 On my side I have very good news for what regards the load time of the kjar generated with the executable model. As I wrote in my former email we are doing our experiments with a reduced version of your original reproducer with only 1 package and 10K rules. As anticipated, before the optimization work that we're doing loading that kjar from plain drl (without the executable model) took 10 seconds while using the executable model required 14 seconds.

 The first experiment that I've done has been parallelizing (for large rule sets as this) how the executable model classes are loaded. This lowered the original 14 seconds to around 6.5 on my laptop and I expect even better improvements on a more beefed hardware.

 However what has been a real game changer is the other improvement suggested by Luca and on which he worked in the last days. What he did was rewriting how the lambdas used in the executable model are generated. Now instead of being inlined with the rest of the code they are placed in external classes. This has a twofold important advantage: 1. the same predicate can be reused multiple times by all the patterns with the same constraint and 2. the whole executable model (excluding the lambdas) is now garbage collectable once the rete/phreak network has been instanced from it.

 Luca's improvement further lowered the time required to create the KieBase from the executable model kjar from 6.5 seconds to only 1.1 seconds. Moreover, for what I wrote above, I'm pretty sure that this will have positive impacts also for what regards the memory occupation. We haven't done any proper measurement on this yet, but still the size of the kjar generated from those 10K rules went down from 15.6M to 9.5 and this is for sure a good sign.

 In case you want to try what we have done so far you can find it on this branch https://github.com/lucamolteni/drools/commits/replace-lambda Note that this works well with the rules that you provided which are pretty simple, but we're aware that this is breaking quite a lot more complex test cases in our code base. For this reason we cannot merge yet this commit into our master, but Luca is continuing to work on this and we're confident that we could have this improvement in our 7.31 release.
	did you give a try to my fix to index generation? Any feedback?

	On my side I have very good news for what regards the load time of the kjar generated with the executable model. As I wrote in my former email we are doing our experiments with a reduced version of your original reproducer with only 1 package and 10K rules. As anticipated, before the optimization work that we're doing loading that kjar from plain drl (without the executable model) took 10 seconds while using the executable model required 14 seconds.

	The first experiment that I've done has been parallelizing (for large rule sets as this) how the executable model classes are loaded. This lowered the original 14 seconds to around 6.5 on my laptop and I expect even better improvements on a more beefed hardware.

	However what has been a real game changer is the other improvement suggested by Luca and on which he worked in the last days. What he did was rewriting how the lambdas used in the executable model are generated. Now instead of being inlined with the rest of the code they are placed in external classes. This has a twofold important advantage: 1. the same predicate can be reused multiple times by all the patterns with the same constraint and 2. the whole executable model (excluding the lambdas) is now garbage collectable once the rete/phreak network has been instanced from it.

	Luca's improvement further lowered the time required to create the KieBase from the executable model kjar from 6.5 seconds to only 1.1 seconds. Moreover, for what I wrote above, I'm pretty sure that this will have positive impacts also for what regards the memory occupation. We haven't done any proper measurement on this yet, but still the size of the kjar generated from those 10K rules went down from 15.6M to 9.5 and this is for sure a good sign.

	In case you want to try what we have done so far you can find it on this branch https://github.com/lucamolteni/drools/commits/replace-lambda Note that this works well with the rules that you provided which are pretty simple, but we're aware that this is breaking quite a lot more complex test cases in our code base. For this reason we cannot merge yet this commit into our master, but Luca is continuing to work on this and we're confident that we could have this improvement in our 7.31 release.