5:24 p.m.
Have been working solely with rules and have now created an overall rule flow that has
enabled me to eliminate parts of the conditions of many rules, because the rules are in
rule flow groups. For example, if the glucose value must be below 40 to get into a rule
flow group called "Below 40", then I do not need to check that the glucose is
below 40 in the condition of every rule in the group.
I have noticed, however, that when a fact is inserted, it appears to activate all rules
for which the conditions match, even though the majority of the rules are not in the rule
flow group. I am interpreting this as simply activating everything applicable, taking
advantage of the Rete, and then the activated rules are filtered by rule flow group. Is
this a correct interpretation?
The corollary question is whether I am using best practice by eliminating
"redundant" conditions from my rules, or whether I should include in those
conditions the constraints that were determining whether the rule flow group becomes
active. If this scaled up to one to two thousand rules, would the activations and
filtering be more costly?
Thanks for any advice. My colleagues and I were very happy to eliminate the redundant
conditions because it makes our rules look simpler, but now concerned may be going down
wrong track.
- Mike
3:05 a.m.
Hi Mike,
I have been working with Drools for only a few months now and am still rather
new to it, but we've have made the same experience, switching from rules only to
rules with flow, and I'm certain it's the right way to go.
The performance implications you mention depend mainly on the way the rules are
set up, I guess.
That is, if you have expensive RHS expressions like eval() you might indeed
profit from keeping your glucose-level condition at the beginning of the rules
which would prevent those expressions from being reevaluted, as far as I
understand.
If you don't I can hardly imagine that activating the rules makes up a
noticeable fraction of the overall time of your process.
We here have a scenario where some rules may be activated only if the user
starting the session has got corresponding privileges.
Since determining the priviliges is not always trivial we definitely wanted to
have that logic in one place. The first thing to do was to use inference
(http://docs.codehaus.org/display/LOGICABYSS/Policy+Encapsulation) but still
already with a few dozen rules and including other constraints the rule RHsides
became rather cluttered. Moreover it was getting increasingly complex to
control the order in which the rules fired, maintanance being another issue.
Using a rule flow we have achieved really good separation of concerns: A rule's
RHS mostly contains exactly those conditions that apply to its intent, none of
the cross-concerns or technicalities. (Hey, what about an AspectDrools
implementation? ;-) )
I am confident that OO lessons apply here, too: If you have a clean design and
performance problems start to show up you are much more likely to solve them
than if you have a tangled web of dependencies.
Greetings,
Gerret
5:14 a.m.
Nice post, Gerret. Cean logic, nicely presented. Separation of concerns vs
tangled web of dependencies..... woooohooo!
On Thu, Feb 18, 2010 at 3:05 AM, Gerret Hansper <gerret.public(a)gmx.de>wrote:
Hi Mike,
I have been working with Drools for only a few months now and am still
rather
new to it, but we've have made the same experience, switching from rules
only to
rules with flow, and I'm certain it's the right way to go.
The performance implications you mention depend mainly on the way the rules
are
set up, I guess.
That is, if you have expensive RHS expressions like eval() you might indeed
profit from keeping your glucose-level condition at the beginning of the
rules
which would prevent those expressions from being reevaluted, as far as I
understand.
If you don't I can hardly imagine that activating the rules makes up a
noticeable fraction of the overall time of your process.
We here have a scenario where some rules may be activated only if the user
starting the session has got corresponding privileges.
Since determining the priviliges is not always trivial we definitely wanted
to
have that logic in one place. The first thing to do was to use inference
(http://docs.codehaus.org/display/LOGICABYSS/Policy+Encapsulation) but
still
already with a few dozen rules and including other constraints the rule
RHsides
became rather cluttered. Moreover it was getting increasingly complex to
control the order in which the rules fired, maintanance being another
issue.
Using a rule flow we have achieved really good separation of concerns: A
rule's
RHS mostly contains exactly those conditions that apply to its intent, none
of
the cross-concerns or technicalities. (Hey, what about an AspectDrools
implementation? ;-) )
I am confident that OO lessons apply here, too: If you have a clean design
and
performance problems start to show up you are much more likely to solve
them
than if you have a tangled web of dependencies.
Greetings,
Gerret
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6061
days inactive
6064
days old
2 comments
3 participants
participants (3)
-
Gerret Hansper -
J Michael Dean -
Pete Carapetyan