[rules-users] Performance of rules in Drools

Wolfgang Laun wolfgang.laun at gmail.com
Fri Mar 21 13:08:59 EDT 2014


"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 at 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
>



More information about the rules-users mailing list