There are some things I can think of in order to optimize determining<br>the minimum and maximum facts.<br><br>One problem with accumulate functions of this kind is that they can't<br>have a "reverse" step. But I'd assume that an implementation of<br>
"first" and "last" locating the facts in a single pass would be better<br>than the described approach.<br><br>Will min/max or first/last have to be recomputed due to the arrival<br>of new or retraction of existing facts? If only the first (new facts)<br>
is possible, rules can be optimized to handle this special scenario.<br><br>-W<br><br><br><div class="gmail_quote">On 13 May 2011 20:49, jkrupka <span dir="ltr"><<a href="mailto:jkrupka@gmail.com">jkrupka@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I've been trying to optimize our stateful rules to run a bit faster,<br>
currently they can't quite keep up with the events coming into the session.<br>
A lot of our rules have to find the fact whose attribute is the<br>
smallest/largest value of all the facts of that type in working memory. I<br>
had originally written the rules to do a min accumulate to find the min<br>
value of the attribute, then a regular pattern to find the actual fact with<br>
that min value. Some of the fact types actually have two fields that must<br>
be used to find the min - think of them as a category and a score. For<br>
those I did two accumulate mins, one to find the lowest category, one to<br>
find the lowest score in that category, and then a third rule to find the<br>
fact with that min category and min score.<br>
<br>
I recently refactored all the rules to use the paradigm of one rule that<br>
matches the fact type I'm interested in, and a second rule that uses the not<br>
operator to express that there be no facts whose attribute is a higher value<br>
than the fact I just matched. In the contrived test I wrote, this seemed to<br>
perform better, but it's hard to tell if they are performing better or not<br>
with production data flowing through them.<br>
<br>
I know of a third option - writing my own accumulate functions - which I<br>
will probably try next. This should allow me to find the min/max fact with<br>
just one iteration over the facts, vs multiple iterations like my first<br>
approach. I don't know how it will compare to using the exists method<br>
though.<br>
<br>
Any feedback on these three different approaches? Any other ideas on the<br>
best way to do this?<br>
<font color="#888888"><br>
--<br>
View this message in context: <a href="http://drools.46999.n3.nabble.com/Best-performing-way-to-process-facts-in-a-particular-order-tp2935847p2935847.html" target="_blank">http://drools.46999.n3.nabble.com/Best-performing-way-to-process-facts-in-a-particular-order-tp2935847p2935847.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>
</font></blockquote></div><br>