[rules-users] Best performing way to process facts in a particular order?

Wolfgang Laun wolfgang.laun at gmail.com
Sat May 14 02:51:05 EDT 2011


There are some things I can think of in order to optimize determining
the minimum and maximum facts.

One problem with accumulate functions of this kind is that they can't
have a "reverse" step. But I'd assume that an implementation of
"first" and "last" locating the facts in a single pass would be better
than the described approach.

Will min/max or first/last have to be recomputed due to the arrival
of new or retraction of existing facts? If only the first (new facts)
is possible, rules can be optimized to handle this special scenario.

-W


On 13 May 2011 20:49, jkrupka <jkrupka at gmail.com> wrote:

> I've been trying to optimize our stateful rules to run a bit faster,
> currently they can't quite keep up with the events coming into the session.
> A lot of our rules have to find the fact whose attribute is the
> smallest/largest value of all the facts of that type in working memory.  I
> had originally written the rules to do a min accumulate to find the min
> value of the attribute, then a regular pattern to find the actual fact with
> that min value.  Some of the fact types actually have two fields that must
> be used to find the min - think of them as a category and a score.  For
> those I did two accumulate mins, one to find the lowest category, one to
> find the lowest score in that category, and then a third rule to find the
> fact with that min category and min score.
>
> I recently refactored all the rules to use the paradigm of one rule that
> matches the fact type I'm interested in, and a second rule that uses the
> not
> operator to express that there be no facts whose attribute is a higher
> value
> than the fact I just matched.  In the contrived test I wrote, this seemed
> to
> perform better, but it's hard to tell if they are performing better or not
> with production data flowing through them.
>
> I know of a third option - writing my own accumulate functions - which I
> will probably try next.  This should allow me to find the min/max fact with
> just one iteration over the facts, vs multiple iterations like my first
> approach.  I don't know how it will compare to using the exists method
> though.
>
> Any feedback on these three different approaches?  Any other ideas on the
> best way to do this?
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Best-performing-way-to-process-facts-in-a-particular-order-tp2935847p2935847.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110514/fe202794/attachment.html 


More information about the rules-users mailing list