[rules-dev] Some performance ideas for 4.1

Mark Proctor mproctor at codehaus.org
Sun Aug 12 18:45:05 EDT 2007


1) Lazy latch nodes, that means the parent node does not propagate 
unless there is something to join against in the child node.

2) Lazy latch querries. Add the DroolsQuery pattern to the end. Find 
either the last unshared node or the root beta node and put in a "block" 
semaphore, that means no data will propagate that is specific to the 
query rule. When the DroolsQuery object is propagated to the JoinNode it 
signals the "block" semaphore to propagate all its data. All data sets a 
specail flag on the Tuple to say that no left memory is to be remember, 
similar to how sequential works. Maybe the check for sequentail node 
memory and this can be merged.

3) Collapse similar shared node groups into single execution units. This 
can be used for sequential mode and standard mode, will need to add a 
method for someone to declare that standard mode will not have it's 
rulebase changed - i.e. its sealed/final or what ever we want to call 
it. We can also optionaly JIT this

4) re-order alpha nodes to maximise sharing, this will also improve 3).

5) Static Agenda. Here the node memories use a linkedhashmap which 
enables the join iteration in propagation order, Activations fire when 
they reach the TerminalNode - there is no Agenda. This will approximate 
a combination of LIFO+Rule Declaration Order and while it will be 
slightly heavier for node memories will do a lot less work for 
situations where there are a large number of conflict sets where only a 
small percentage of them fire.

6) Allow some data to be marked as "closed world". This means the data 
will only ever be created inside of the WorkingMemory. This way we can 
analyse the rules and handle the life cycle of the data and allow us to 
auto-unpropagate it back to the ObjectTypeNode when we know it will have 
no further impact.



More information about the rules-dev mailing list