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

From: nesta <nesta.fdb(a)163.com&gt; Subject: Re: [rules-users] optimization on a lot of simple rules To: rules-users(a)lists.jboss.org Date: Monday, July 20, 2009, 4:14 AM 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(a)163.com&gt; 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(a)163.com&gt; 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-tp24556724p24... >> >> Sent from the drools - user mailing list archive at Nabble.com. >> >> >> >> _______________________________________________ >> >> rules-users mailing list >> >> rules-users(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> > >> > _______________________________________________ >> > rules-users mailing list >> > rules-users(a)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-tp24556724p24... >> Sent from the drools - user mailing list archive at Nabble.com. >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > rules-users(a)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-tp24556724p24... Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users