[rules-users] Short circuiting evaluations on LHS

[Anstis, Michael (M.)]

All facts are matched against all patterns upon insertion into working
memory. The (Drools) techniques you describe affect the execution of
activations (i.e. RHS) not pattern matching.
 
I think (but it's a vague recollection) however that the sequence of
patterns has an affect (so you want most restrictive first and least
restrictive last). So my thought would be to try to add a pattern to the
start of each rule that checks whether there are more than one survivor
before the other (more expensive) patterns. Just a thought from what I
recall - I haven't tried it:-
 
rule "expensive"
    when
        ArrayList( size > 1 ) from collect( SuperClassOfAllFacts( ) )
        someExpensivePattern( )
    then
        something();
    end
 
 


  _____  

From: rules-users-bounces at lists.jboss.org
[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Newman, Jason
Sent: 03 April 2008 20:07
To: rules-users at lists.jboss.org
Subject: [rules-users] Short circuiting evaluations on LHS



I am currently using Drools 4.0 to determine the best choice out of a data
set based on business rules. The rules eliminate (retract) facts until a
single fact survives, and is used for additional processing. I have found
Drools to be a great solution for this problem, and plan to role it out for
additional survivor rules. My problem is in optimization - this is
essentially a batch processing application, and speed is very important (of
course it is  - show me the case where it isn't, right?).

Some of the later evaluations in the rules are fairly expensive (invoking
complex queries from the database), and generally apply to only a small set
of the use cases. For most use cases, the survivor will have been determined
after the first or second rule, so I only want to perform the expensive
evaluations if necessary. I have not found a way to avoid or schedule the
LHS evaluations from firing when inserting the fact into the working memory.
I have played around with agenda groups and rule flows, but haven't had any
luck. The only way I can think of at this point is to break my rules into
separate rule bases, and "manually" copy survivors from one working memory
to the next, performing my own short circuiting outside of the rules being
fired. 

Is there any other technique that I have missed? From a maintenance
standpoint, I would prefer to be able to use one rule base/rule flow to
manage the rules (there are only about 10 total rules, so the base is not
very large - and I would have to break it into 4 or 5 different rule bases,
which seems like it will be a pain across the 5 different areas I need to
implement the rules.)

Thanks, 

-Jason 


The information transmitted (including attachments) is

covered by the Electronic Communications Privacy Act,

18 U.S.C. 2510-2521, is intended only for the person(s) or

entity/entities to which it is addressed and may contain

confidential and/or privileged material. Any review,

retransmission, dissemination or other use of, or taking

of any action in reliance upon, this information by persons

or entities other than the intended recipient(s) is prohibited.

If you received this in error, please contact the sender and

delete the material from any computer.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080407/c5c30840/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7206 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20080407/c5c30840/attachment.bin