<div><br></div> Listen to what others are saying in this thread... it is very good advice, specially what wolfgang suggests bellow regarding collapsing evals.<div><br></div><div> Also, I just read the example in your link where you have multiple accumulates in a single rule... that is *bad*....</div>
<div><br></div><div> 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. </div>
<div><br></div><div> 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.</div>
<div><br></div><div> Edson<br><br><div class="gmail_quote">On Wed, Jul 25, 2012 at 7:42 AM, Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com" target="_blank">wolfgang.laun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A last effort from my side.<br>
<br>
Given any number of bound variables a, b, c: to determine whether an<br>
arbitrary boolean expression involving arithmetic and comparison<br>
operators, a single eval() is sufficient and preferable to a CE<br>
combination involving the CE operators "and", "or", "not" combining<br>
many evals.<br>
<br>
Instead of<br>
not( eval( a == 1 ) )<br>
use<br>
eval( ! (a == 1) ) // or better<br>
eval( a != 0 )<br>
<br>
Instead of<br>
eval( a == 1 ) or eval( b == 1 )<br>
use<br>
eval( a == 1 || b == 1 )<br>
<br>
Instead of<br>
eval( a == 1 ) and eval( b == 1 )<br>
use<br>
eval( a == 1 && b == 1 )<br>
<span class="HOEnZb"><font color="#888888"><br>
-W<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 25/07/2012, fx242 <<a href="mailto:drools@fx242.com">drools@fx242.com</a>> wrote:<br>
> Thanks for your explanation Edson, it makes sense now I think!<br>
> Basically what you are saying is that there is a limit, beyond which is no<br>
> longer feasible to use more ORs on a rule.<br>
><br>
><br>
> Edson Tirelli-4 wrote<br>
>><br>
>> You are trying to avoid the issue. As reported by others, your<br>
>> conditions should be inside the patterns, not in "or'd" evals in the end,<br>
>> and yes, it is possible to generate rules like that in an automated<br>
>> program.<br>
>><br>
><br>
> Sadly I don't see how, as some of my rules have arbitrary arithmetic<br>
> involving more than one variable inside the Number(), for more context see<br>
> the example I've put on<br>
> <a href="http://drools.46999.n3.nabble.com/drools-arithmetics-without-eval-td3823232.html" target="_blank">http://drools.46999.n3.nabble.com/drools-arithmetics-without-eval-td3823232.html</a>.<br>
><br>
> For this case I think I will try to invert the logic and get rid of the<br>
> ORs:<br>
> not(A or B) => not(A) and not(B).<br>
><br>
> Best regards,<br>
> TL<br>
><br>
><br>
><br>
><br>
> --<br>
> View this message in context:<br>
> <a href="http://drools.46999.n3.nabble.com/Slow-compilation-4h-for-a-single-rule-tp4018855p4018894.html" target="_blank">http://drools.46999.n3.nabble.com/Slow-compilation-4h-for-a-single-rule-tp4018855p4018894.html</a><br>
> Sent from the Drools: User forum mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> rules-users mailing list<br>
> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>
</div>