[rules-users] Reading DRL file with large number of rules

[kpowerinfinity]

Dear all,

Thanks for the responses. We would like to use a rules engine because
we need it for a generalized set of rules. And they could be more
complicated than a map lookup. However, it does seem from the numbers
reported above that there might be some issues in reading the rule and
it should not take so much time. I will investigate and get back.

Regards
Krishna.

--
http://kpowerinfinity.wordpress.com
http://www.linkedin.com/in/kpowerinfinity




2010/2/8 Edson Tirelli <ed.tirelli at gmail.com>:
>
>    Hi people,
>
>    We are talking about several things at the same time here, so we need to
> organize our answers to not turn information into noise.
>
> * Me and Wolfgang were suggesting that Krishna evaluates his need for a
> rules engine. There are several requirements that are met by such a product,
> but if all he needs is to execute a piece of code based on the value of an
> attribute, there are simpler alternatives. But of course, only Krishna,
> knowing all of the requirements can know what is best.
>
> * Krishna's problem is that compilation is taking too long or not finishing
> at all. The example program I sent in my e-mail, shows that it is possible
> to compile 20k rules and load them in memory, so it is obvious that there is
> something different in Krishna's program, but we don't have any more info on
> what it could be.
>
> * Felipe: since we are talking about compilation time only (not runtime),
> and since Drools handles the consequence block as a black box, there
> shouldn't be any noticeable difference in compiling a single System.out call
> or an object instantiation with a few attribute setting calls. The real
> overhead is in initializing the compiler to compile 20k different blocks of
> code. The complexity of the block code has little impact (although obviously
> there is a bit higher cost) on the compilation time compared to everything
> else.
>
> * djb, Thomas is correct. The whole point of Rete is to only check and
> reactivate rules that could be impacted by each fact, minimizing the cost of
> rules re-evaluation. This goes back to what me and Wolfgang were talking
> about. If you would make a naive algorithm with 20k "if"s, all of them would
> be executed for each new fact, causing the application to run with very poor
> performance. Although, it is possible to use simple techniques and still get
> good performance without using Rete ***if*** your rules are simple enough
> that you can manage them. Usually, it is best to just use a rules engine.
>
>     Hope comments above help to clarify things.
>
>     Edson
>
> 2010/2/8 Swindells, Thomas <TSwindells at nds.com>
>>
>> But isn't the way Rete work is that it creates a decision tree to work out
>> which rules to evaluate.  Right at the top of the tree will be a check on
>> the fact type that is being inserted, as the fact being inserted doesn't
>> match against any of the 20k rules (it is a totally different object type)
>> the evaluation will finish immediately with no further rule evaluations.
>>
>> Thomas
>>
>> > -----Original Message-----
>> > From: rules-users-bounces at lists.jboss.org [mailto:rules-users-
>> > bounces at lists.jboss.org] On Behalf Of djb
>> > Sent: 08 February 2010 14:41
>> > To: rules-users at lists.jboss.org
>> > Subject: Re: [rules-users] Reading DRL file with large number of rules
>> >
>> >
>> > I second Felipe -
>> > since every time you modify working memory (eg. insert), it refires all
>> > rules, so for 20k rules, you're looking at something like 350-400
>> > million
>> > firings :)  Or, without no-loop, it will never end.  Though perhaps
>> > salience
>> > skips this second problem.
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> > http://n3.nabble.com/Reading-DRL-file-with-
>> > large-number-of-rules-tp190032p192446.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
>>
>>
>>
>> **************************************************************************************
>> This message is confidential and intended only for the addressee. If you
>> have received this message in error, please immediately notify the
>> postmaster at nds.com and delete it from your system as well as any copies. The
>> content of e-mails as well as traffic data may be monitored by NDS for
>> employment and security purposes. To protect the environment please do not
>> print this e-mail unless necessary.
>>
>> NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
>> 4EX, United Kingdom. A company registered in England and Wales. Registered
>> no. 3080780. VAT no. GB 603 8808 40-00
>>
>> **************************************************************************************
>>
>> This message is confidential and intended only for the addressee. If you
>> have received this message in error, please immediately notify the
>> postmaster at nds.com and delete it from your system as well as any copies. The
>> content of e-mails as well as traffic data may be monitored by NDS for
>> employment and security purposes.
>> To protect the environment please do not print this e-mail unless
>> necessary.
>>
>> An NDS Group Limited company. www.nds.com
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> --
>  Edson Tirelli
>  JBoss Drools Core Development
>  JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>