<div><br></div> All,<div><br></div><div> Please let me re-emphasize something from my e-mail: "<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">for the general case [eager evaluation] is still better than doing selective evaluation". Unless you are having performance problems for your specific use case, you should not be worrying about this, as the engine is optimized for the general use case.</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"> If you *are* having performance problems, then there is a number of possible factors that need to be analyzed, one of which is the possible use of control facts to prevent beta evaluation. So, don't think that control facts are a general solution that will work for everybody... it is quite the opposite, control facts are only worth for a minority of very specific cases, because depending on your situation, it might be very costly to do the phase switch on a control fact.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"> Regarding the question on the rule-flow optimizations, there are optimizations there... for instance, activations don't go into the main agenda until the rule-flow group is activated, and it is usually much cheaper to maintain activations in the separate groups than it is to maintain them on the main agenda... </span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"> Edson<br>
</span></font><br><div class="gmail_quote">2011/3/21 FrankVhh <span dir="ltr"><<a href="mailto:frank.vanhoenshoven@agserv.eu">frank.vanhoenshoven@agserv.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
This is a very interesting discussion, so I re-read the Drools Flow manual.<br>
IN section 8.1, it is stated as one of the reasons to use rules in your<br>
process:<br>
<br>
Performance: Rule evaluation is optimized.<br>
<br>
How do I have to understand this? Does rule evaluation only happens for the<br>
rules that are in the current ruleflowgroup? Because the above conversation<br>
seems to imply it isn't.<br>
<br>
Regards,<br>
Frank<br>
<div class="im"><br>
<br>
Swindells, Thomas wrote:<br>
><br>
> That's probably the best way to go. I think it's a case of experimentation<br>
> to work out what runs best (and please report your results). Things to<br>
> consider are what order you have the conditions in the rules (the control<br>
> fact first is probably most efficient but may be worth comparing with it<br>
> at the end) and the order you insert facts - do you insert the control<br>
> fact first or last.<br>
><br>
> Thomas<br>
><br>
> From: <a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a><br>
> [mailto:<a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>] On Behalf Of Vincent Legendre<br>
> Sent: 21 March 2011 13:47<br>
> To: Rules Users List<br>
> Subject: Re: [rules-users] Limiting rule evaluation--not firing<br>
><br>
> ok.<br>
> So the only way to do that is to add a control fact, and update it at<br>
> runtime...<br>
</div>> Do you think that using the &quot;control fact&quot; method will speed up<br>
<div class="im">> the execution time for a large ruleset that have different ruleflow-group<br>
> ?<br>
</div>> My feeling is yes, especially if &quot;first&quot; rules does many<br>
<div class="im">> updates, but I haven't done any tests.<br>
><br>
> Le 21/03/2011 14:37, Swindells, Thomas a écrit :<br>
> The thing to remember is that fact evaluation occurs at object<br>
> insert/update time, not at the point you call fireAllRules. Salience,<br>
> Agenda and rufeflow control on the other hand are runtime conditions which<br>
> control which rules are actually activated in what order.<br>
><br>
> Thomas<br>
><br>
> From:<br>
</div>> <a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>&lt;mailto:<a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>&gt;<br>
<div class="im">> [mailto:<a href="mailto:rules-users-bounces@lists.jboss.org">rules-users-bounces@lists.jboss.org</a>] On Behalf Of Vincent Legendre<br>
> Sent: 21 March 2011 13:34<br>
> To: Rules Users List<br>
> Subject: Re: [rules-users] Limiting rule evaluation--not firing<br>
><br>
> And what about ruleflow-group ?<br>
> There is no network filtering for that too ? The ruleflow-group behaves<br>
> like an agenda filter, but still evaluate all nodes ?<br>
</div>> Could we imagine setting &quot;tags&quot; to nodes, and stop propagation<br>
<div><div></div><div class="h5">> for node that does not declare the current task tag ?<br>
><br>
><br>
> Le 21/03/2011 14:20, Edson Tirelli a écrit :<br>
><br>
> The algorithm as is does eager evaluation, as for the general case that<br>
> is still better than doing selective evaluation.<br>
><br>
> If, in your case, the decision of which rules to fire is an arbitrary<br>
> application decision, and not based on the actual constraints of the rules<br>
> themselves, then the only way would be by creating a control fact:<br>
><br>
> rule 1<br>
> when<br>
> ControlFact( phase == Phase.ONE )<br>
> ...<br>
><br>
> rule 2<br>
> when<br>
> ControlFact( phase == Phase.TWO )<br>
> ...<br>
><br>
> This way, if the control fact is the first pattern in each rule it<br>
> effectively disables all the beta evaluations for rules of phases other<br>
> than the current one. Just be aware that by blocking the eager evaluation<br>
> this way, phase switches are heavier than without the control fact, where<br>
> most constraints were already previously evaluated. Obvious, but worth<br>
> saying out loud... :)<br>
><br>
> There is also a feature that Leonardo is working on that makes the<br>
> engine automatically unlink and relink parts of the network, based on the<br>
> existence and possibility of matching the other required facts in a rule<br>
> LHS. It might achieve similar results to what you are looking for in some<br>
> cases, but that is totally based on the constraints in there and not on<br>
> any arbitrary application decision.<br>
><br>
> Edson<br>
><br>
><br>
><br>
> ________________________________<br>
><br>
> **************************************************************************************<br>
> This message is confidential and intended only for the addressee. If you<br>
> have received this message in error, please immediately notify the<br>
</div></div>> <a href="mailto:postmaster@nds.com">postmaster@nds.com</a>&lt;mailto:<a href="mailto:postmaster@nds.com">postmaster@nds.com</a>&gt; and delete it from<br>
<div class="im">> your system as well as any copies. The content of e-mails as well as<br>
> traffic data may be monitored by NDS for employment and security purposes.<br>
> To protect the environment please do not print this e-mail unless<br>
> necessary.<br>
><br>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18<br>
> 4EX, United Kingdom. A company registered in England and Wales. Registered<br>
> no. 3080780. VAT no. GB 603 8808 40-00<br>
> **************************************************************************************<br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
><br>
> rules-users mailing list<br>
><br>
</div>> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>&lt;mailto:<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>&gt;<br>
<div class="im">><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>
> _______________________________________________<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>
<br>
</div><font color="#888888">--<br>
View this message in context: <a href="http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluation-not-firing-tp2695533p2710262.html" target="_blank">http://drools-java-rules-engine.46999.n3.nabble.com/Limiting-rule-evaluation-not-firing-tp2695533p2710262.html</a><br>
</font><div class="im">Sent from the Drools - User mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">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"><br>-- <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>