[rules-dev] Some performance ideas for 4.1

[Mark Proctor]

some more ideas :)

Network re-writting through network analysis.

For multi-threaded systems look to which subsystems can maybe have there 
own thread. The Agenda is a good candidate here, I'm sure there are others.

Mark

Mark Proctor wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>