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.tire...@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 <tswinde...@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-boun...@lists.jboss.org [mailto:rules-users- >> > boun...@lists.jboss.org] On Behalf Of djb >> > Sent: 08 February 2010 14:41 >> > To: rules-users@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@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 >> postmas...@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 >> postmas...@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@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users