<br>&nbsp;&nbsp;&nbsp; That is a half-truth (if such thing exists...) :)<br>&nbsp;&nbsp;&nbsp; You will indeed avoid the beta evaluations (joins) that are more expensive than alpha evaluations, and also prevent the rule activations. But alpha evaluations will still happen. So, I would say, you would prevent 90%(?) of the engine work with such strategy, but there would be still a minor 10%(?) cost, that may be very acceptable in your case. The percentages are pure guess, since they will vary greatly depending on your rules and the CEs you are using, but they give you a general idea.
<br><br>&nbsp;&nbsp;&nbsp; []s<br>&nbsp;&nbsp;&nbsp; Edson<br><br><br><div><span class="gmail_quote">2007/8/15, Yuri &lt;<a href="mailto:ydewit@gmail.com">ydewit@gmail.com</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edson Tirelli &lt;tirelli &lt;at&gt; <a href="http://post.com">post.com</a>&gt; writes:<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Yuri,&nbsp;&nbsp;&nbsp;&nbsp;Right now, the only way is to work with different rule bases and<br>working memories. Even using agenda-groups or rule-flow, rules are still being
<br>eagerly evaluated, as this is how standard Rete works.<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; The problem of creating and canceling too many activations is a known<br>problem and the only way around it right now is sequential mode, but sequential
<br>mode has some restrictions on what you can do. For instance, you must work with<br>a stateless working memory and can not modify/retract facts in your rules to<br>work with sequential mode, but it will give you big performance boosts.
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; We are evaluating the possibility of creating physical network partitions<br>for next version, but that will require some R&amp;D yet.&nbsp;&nbsp;&nbsp;&nbsp;[]s&nbsp;&nbsp;&nbsp;&nbsp;Edson<br><br>Edson, thanks for the explanation!<br><br>At this point we are considering a scheme to create additional working memories
<br>and have a way to propagate inserts/updates/retracts selectively.<br><br>Is my assumption correct that if I make sure a &quot;barrier&quot; column/constrains sits<br>at the top of the rete network that I could delay the insertion of the &quot;barrier&quot;
<br>and achieve what I am looking for without having to split the working memories?<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">https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>&nbsp;&nbsp;Edson Tirelli<br>&nbsp;&nbsp;Software Engineer - JBoss Rules Core Developer
<br>&nbsp;&nbsp;Office: +55 11 3529-6000<br>&nbsp;&nbsp;Mobile: +55 11 9287-5646<br>&nbsp;&nbsp;JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>