[rules-users] optimization on a lot of simple rules

[nesta]

Thanks very much.
But if for every rule, there is one algorithm or discount which means that
result has nothing related with Product's id and usage. I can't merge all
rules in one rule. At the same time, besides Product and Decision fact type,
there are more fact types.
For example:
rule 1
    when
         Decision()
         Subscriber(gender == "male" or "female")
         Service(name == "ftp" or "http")
         Product(id == 1)
         ......
   then
         ......
end
rule 2
    when
         Decision()
         Subscriber(gender == "male" or "female")
         Service(name == "ftp" or "http")
         Product(id == 2)
         ......
   then
         ......
end

.....
.....

In this scenario, if there are 1000 rules,  there will be a lot of JoinNode.
But in runtime, there is only one Decision instance, one Subscriber instance
and Service instance.

If I define all data in one fact type, I think that there are not a lot of
JoinNodes.

Is there any other method?



Wolfgang Laun-2 wrote:
> 
> Well, what is the realtion between id, usage and the result that's to be
> stored in a Decision or a global?
> 
> Typically, such rules could be written as
> 
> rule x
> no-loop true
> when
>     $d : Decision()
>     $p :Product( id == 1, $usage : usage )
> then
>     compute/store value, depending on the formula for id == 1 (using
> usage)
> end
> // similar rule for id == 2,3,...
> 
> If value is a straightforward function of id (and usage), then implement a
> function compValue and use a single rule, e.g.:
> 
> rule x
> no-loop true
> when
>     $d : Decision()
>     Product( $id : id, $usage : usage)
> then
>    modify $d value to compValue( $id, $usage )
> 
> Distinguishing all individual combinations of id and usage on the LHS
> seems
> excessive.
> 
> The ordering of CEs also affects execution times.
> 
> -W
> 
> On 7/20/09, nesta <nesta.fdb at 163.com> wrote:
>>
>>
>> In this scenario, there are 1000 products, different product has
>> different
>> price, besides this, the price is affected by usage. I want to use
>> Product.id to match the rules.
>>
>> As you mentioned "The crude duplication of rules where only the constant
>> to
>> be matched with
>> Product.id varies can, most likely, be avoided."
>>
>> How to avoid it in this scenario?
>>
>>
>> Wolfgang Laun-2 wrote:
>> >
>> > It's difficult to suggest an optimized form for your rules 1-infinity,
>> > since
>> > we do not know what you want to achieve.
>> >
>> > The crude duplication of rules where only the constant to be matched
>> with
>> > Product.id varies can, most likely, be avoided.
>> >
>> > -W
>> >
>> >
>> >
>> > On Sun, Jul 19, 2009 at 3:15 PM, nesta <nesta.fdb at 163.com> wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> I am a newbie in drools. There are a lot of simple rules in a
>> scenario.
>> >> For example
>> >> rule 1
>> >>    when
>> >>        Product( id ==1, usage == 1)
>> >>        $decision : Decision()
>> >>    then
>> >>         $decision.setValue(1);
>> >> end
>> >>
>> >> rule 2
>> >> when Product( id ==2, usage == 1)
>> >>  $decision : Decision()
>> >> rule 3
>> >> when Product( id ==3, usage == 1)
>> >>  $decision : Decision()
>> >> rule 4
>> >> when Product( id ==4, usage == 1)
>> >>  $decision : Decision()
>> >> rule 5
>> >> when Product( id ==5, usage == 1)
>> >>  $decision : Decision()
>> >> ......
>> >>
>> >> I have a Product fact whose id = 5 and usage = 1, in my first
>> thinking,
>> >> only
>> >> rule 5 is matched, there should be not much more different between 1
>> rule
>> >> and a lot of rules in runtime.
>> >>
>> >> But the result shows that they are different. More rules will cost
>> more
>> >> time. If there are 1 thousand rules, some Node and Sink will execute 1
>> >> thousand times.
>> >>
>> >> My question is how to optimize this scenario?
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/optimization-on-a-lot-of-simple-rules-tp24556724p24556724.html
>> >> Sent from the drools - user mailing list archive at Nabble.com.
>> >>
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> rules-users at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/optimization-on-a-lot-of-simple-rules-tp24556724p24563725.html
>> Sent from the drools - user mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> 

-- 
View this message in context: http://www.nabble.com/optimization-on-a-lot-of-simple-rules-tp24556724p24566350.html
Sent from the drools - user mailing list archive at Nabble.com.