[rules-dev] Some performance ideas for 4.1

[Geoffrey De Smet]

Mark Proctor wrote:
> 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.

+1 this would allow drools-solver-localsearch to start thinking about 
using drl's to generate the moves.

Explanation:
Moves are generated once every step, but a step does and undoes 2000+ 
moves (= small change + a fireAll score rules), after which the facts 
have not changed (due to the undo-ing). Then for the next step a small 
changes is done (the step taken) and the moves are generated again (= a 
fireAll move generating rules).

>>
>> 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.

Is this forward chaining in query's?
Would be nice to combine this with the feature of allowing the reuse of 
query's in from:
   from accumulate(myQuery, count())

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

solver doesn't change it rules after initialization.
It does change facts:
   - move-trigged fact changes ("appoint lesson4 to timeslot 3")
   - real-time-problem-update fact changes ("add a lesson9 with teacher3 
and group4") (not yet implemented)
But for drools this are all mere facts.

>>
>> 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.

With kind regards,
Geoffrey De Smet

>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>