[rules-users] Slow compilation (4h) for a single rule

[Edson Tirelli]

   You are trying to avoid the issue. As reported by others, your
conditions should be inside the patterns, not in "or'd" evals in the end,
and yes, it is possible to generate rules like that in an automated program.

   Now, the reason it is taking so long is because of the "or"s. I don't
think there is any bug there. Just for you to understand, an OR is just
syntax sugar for multiple rules. So if you have a rule that says:

A() or B()

   The engine is actually creating 2 rules:

rule 1 when
   A()
...

rule 2 when
   B()
...

    I.e., it generates all possible combinations of rules, one for each of
your logical branches.

    Now, I quickly counted 26 "or"s in your rule. It is quite possible that
the engine is generating all possible combinations of rules for all your
ORs, and that is roughly (there are some factors that influence the number
of rules): 2^26 == 67108864 rules. To compile 67 million rules, it can
indeed take some time.

    I don't know for sure if that is the case without looking at your
application, but to solve your problem you should fix your rule generation,
not look for a problem elsewhere.

    Edson

On Tue, Jul 24, 2012 at 9:29 AM, fx242 <drools at fx242.com> wrote:

> I understand that the rule looks pointless and under-optimized, but it's
> the
> only way I could represent this kind of rule in an automated way (I didn't
> write the rule by hand). Basically with these rules I try to pre-compute
> the
> amount of some products on the WM (using count() inside a accumulate
> function) resulting in a Number(), and then on the last condition I
> evaluate
> some arbitrary arithmetic operation using the variables inside the Number()
> object.
> For more details for examples see my previous post where I've tried to
> address this issue:
>
> http://drools.46999.n3.nabble.com/drools-arithmetics-without-eval-td3823232.html
>
> So, considerations apart of the way the rule is written, I still think
> there
> is a bug or something similar on the RETE compiler, that causes this rule
> to
> be processed in a very expensive way. Can someone confirm this, and try to
> sugest an alternative? Maybe It's something that is already fixed on newer
> versions as sugested by Esteban?
>
> Regards,
> Tiago Lopes
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/Slow-compilation-4h-for-a-single-rule-tp4018855p4018870.html
> Sent from the Drools: User forum mailing list archive at Nabble.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120724/58938630/attachment.html