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@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Newman, Jason
Sent: 03 April 2008 20:07
To: rules-users@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.