[rules-users] @Rete Experts: the finer meshes of matching

[Wolfgang Laun]

To sum it up: it doesn't hurt if you put constraints using == against one out of
a wide range of values up front, and chances are good that it will improve
performance.

On Fri, Apr 9, 2010 at 1:55 AM, Mark Proctor <mproctor at codehaus.org> wrote:
> On 08/04/2010 19:56, Wolfgang Laun wrote:
>> It's common Rete wisdom to order patterns by expected frequency of
>> matches, in descending order.

s/descending/ascending/ Was I thinking of descending probability? ;-)

Thanks, Mark!
-W

>> Does this also apply to constraints within a single pattern? For
>> example, is it better to write, for a New York address
>>     Address( street == "Broadway", number == 1)
>> than
>>     Address( number == 1, street == "Broadway")
>> or is this irrelevant?
>>
> Drools will iterate to find the first == constraints, both literal and
> vairable constraints. So if != or < are first, that doesn't matter. For
> multiple literal constraints, should definitely have the strongest
> descriminator first - although it's not quite that simple. You also want
> the descriminator that provides the highest chances of node share
> amoung. == literal constraints are hashed so the wider the want out
> (alternative values) the more scalable performance you'll see. Drools
> actually attempts to hash the fanout of consequence child nodes in the
> alpha network, if they to are ==, but rarely is there any real gain from
> this as after the first level of descrimination there is general not a
> consequence wide fanout based on the previous constraints value.
>
> There are deterministic algorithms that claim to analyse a network to
> re-order literal constraints to maximise node sharing, but that's not
> something we have, patches please  :)
>
> If it's a variable constraint we support composite indexing. Drools
> produces a composite index based on the first 3 ==  constraints. Whether
> the order of those first 3 impacts perf, not sure. But if there was a
> 4th variable constraint and that was the strongest descriminator, it
> would get left out of the index; when in reality it's probably the most
> important constraint as part of the index.
>
> Mark
>> Or does it depend on either constraint (on each own) also occurring in
>> another rule without the other one?
>>
>> I guess this could also depend on the implementation, i.e., how
>> fine-grainedly condition sharing is being done.
>>
>> Cheers
>> Wolfgang
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>