Re: [rules-dev] Some performance ideas for 4.1

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. _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev