Listen to what others are saying in this thread... it is very good advice, specially what wolfgang suggests bellow regarding collapsing evals.
Also, I just read the example in your link where you have multiple accumulates in a single rule... that is *bad*.... For those that attended or saw my presentation on best practices, an easy way to estimate the performance of accumulates is to remember that the performance of accumulates in a single rule is polinomial: O(n^a), where "n" is the number of matching facts and "a" is the number of accumulates you have in the same rule. So, if you have 1 rule with 5 accumulates, the performance will be n^5. If instead you break the accumulates into 5 rules with one accumulate each, you get a performance of O(5n) that is much better. Edson On Wed, Jul 25, 2012 at 7:42 AM, Wolfgang Laun <wolfgang.l...@gmail.com>wrote: > A last effort from my side. > > Given any number of bound variables a, b, c: to determine whether an > arbitrary boolean expression involving arithmetic and comparison > operators, a single eval() is sufficient and preferable to a CE > combination involving the CE operators "and", "or", "not" combining > many evals. > > Instead of > not( eval( a == 1 ) ) > use > eval( ! (a == 1) ) // or better > eval( a != 0 ) > > Instead of > eval( a == 1 ) or eval( b == 1 ) > use > eval( a == 1 || b == 1 ) > > Instead of > eval( a == 1 ) and eval( b == 1 ) > use > eval( a == 1 && b == 1 ) > > -W > > On 25/07/2012, fx242 <dro...@fx242.com> wrote: > > Thanks for your explanation Edson, it makes sense now I think! > > Basically what you are saying is that there is a limit, beyond which is > no > > longer feasible to use more ORs on a rule. > > > > > > Edson Tirelli-4 wrote > >> > >> You are trying to avoid the issue. As reported by others, your > >> conditions should be inside the patterns, not in "or'd" evals in the > end, > >> and yes, it is possible to generate rules like that in an automated > >> program. > >> > > > > Sadly I don't see how, as some of my rules have arbitrary arithmetic > > involving more than one variable inside the Number(), for more context > see > > the example I've put on > > > http://drools.46999.n3.nabble.com/drools-arithmetics-without-eval-td3823232.html > . > > > > For this case I think I will try to invert the logic and get rid of the > > ORs: > > not(A or B) => not(A) and not(B). > > > > Best regards, > > TL > > > > > > > > > > -- > > View this message in context: > > > http://drools.46999.n3.nabble.com/Slow-compilation-4h-for-a-single-rule-tp4018855p4018894.html > > Sent from the Drools: User forum mailing list archive at Nabble.com. > > _______________________________________________ > > rules-users mailing list > > rules-users@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users