Once the KB+WM is in place, using either approach, it is merely the
insertion time of facts to be matched that counts. A fact's attributes
need to be compared to these parameter sets, given either explicit in
rules or as data in parameter facts.
Comparing a fact f to a set of another facts S requires the comparison
of each attribute of f with all corresponding parameter attributes in
S. Indexing should make this more efficient than it sounds.
With parameters explicit in rules, the rule compiler has the
possibility of combining constraints with identical value into a
single node, thereby reducing the number of necessary comparisons.
In both scenarios, the order of the comparisons should matter: it's
best if the first attribute reduces the number of potential matches
maximally.
That said, the only way to gain some confidence is to run a few
benchmarks, and you'll have to roll your own - only you know the
relevant details. I've exercised the two scenarions outlined before,
and the answer was that one is slower by 40% than the other, with ~ 10
sec for 1000000 facts, comparing 2 string and 2 int attributes for
equality. So, it doesn't seem to matter much, which way you choose.
But this test is fairly naive - I don't want to be quoted saying that
this is faster than that.
I do think that using parameter facts has some handling advantages.
Cheers
-W
On 23/03/2014, Seb Geek <geekseb(a)gmail.com> wrote:
More efficient w.r;t runtime !
Actually, we generate (automatically by a batch) one rule for each demand
(set of parameters), even if the demand use the same "template" than an
other previous demand with other parameters, so code in rules seams to be
very duplicated code at the exeption of parameters values ...
For efficiency at runtime (in term of response time), we want to know if
"code only one rule (with the parameter as a fact in when clause) and
*not *generate
different rules for different parameters" will be more efficient or not ?
Regards
Sébastien
2014-03-21 18:08 GMT+01:00 Wolfgang Laun <wolfgang.laun(a)gmail.com>:
> "More efficient" w.r.t. runtime, maintenance, development effort,...?
>
> Writing individual rules is quick, bad for maintenance, and probably
> best, if a session has only a few inputs as it starts fast from a
> precompiled rule base.
>
> Parameter facts take a little time for development, are very good for
> maintenance (see below) and have a tolerable overhead if they are not
> too numerous and/or the session runs long.
>
> What should be considered is that a set of parameter facts can be
> maintained by non-technical personnel, e.g., in a spreadsheet or in
> some other data preparation tool. This could be a boon for long-ter
> maintenance.
>
> -W
>
>
> On 21/03/2014, Seb Geek <geekseb(a)gmail.com> wrote:
> > Hello,
> >
> > I have a list of very similar rules executed in Drools and some
> performance
> > problems appear ... I want some advices to choose between two
> > "direction"
> > in order to correct them ...
> >
> > First the context :
> > I have to execute always the same check but with different level or
> > "parameters".
> > For example,
> > - in the first demand (rule for our client) i have to count and
> > retrieve
> > the list all Article that have a family code equals to 'A', 'B'
or 'C'
> and
> > execute the then clause only if there is 3 elements in the filtered
> > list.
> > - in the second demand (rule for our client) i have to count and
> > retrieve
> > the list all Article that have a family code equals to 'B' or
'C' and
> > execute the then clause only if there is 4 elements in the filtered
> > list
> > and so on ...
> >
> > The number of different group of parameter values and the values of
> theses
> > parameters will change over time ...
> >
> > The question is : is it more efficient to implement a lot of different
> > rules, each with their parameter in the code OR is it more efficient to
> > implement only one rule with an additional object as a drools fact
> > containing different parameter's values ?
> >
> > Thanks for your help
> > Sébastien
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-users
>