I might in long time implement it and provide a patch, using a custom
specialized node like Edson described.
However, a very rough log-based benchmark seems to indicate that this
sum rule [2] isn't the weak spot in my app's performance:
I started out with a couple of rules.
- log: 4seconds per 90 iterations
- added a rule [1] that uses exists
- log: 12seconds per 90 iterations
- added the sum rule [2] that uses logically asserted objects and always
recalculates the sum based on those
- log: still around 12-13 seconds per 90 iterations
The exists rule seems to tripled the execution time.
I 'll now focus on getting a decent benchmark system up,
so I can compare combinations of different strategy's in my app
(taseree) and maybe also of different rules. If I notice anything
interesting about the rule engine performance, I 'll post it here too :)
With kind regards,
Geoffrey De Smet
https://svn.sourceforge.net/svnroot/taseree/trunk
[1]
query "multipleMatchesPerTeamPerDay1"
Match( $id : id, $team : homeTeam, $day : day );
exists Match( id > $id, homeTeam == $team, day == $day );
end
query "multipleMatchesPerTeamPerDay2"
Match( $id : id, $team : homeTeam, $day : day );
exists Match( id > $id, awayTeam == $team, day == $day );
end
query "multipleMatchesPerTeamPerDay3"
Match( $id : id, $team : awayTeam, $day : day );
exists Match( id > $id, homeTeam == $team, day == $day );
end
query "multipleMatchesPerTeamPerDay4"
Match( $id : id, $team : awayTeam, $day : day );
exists Match( id > $id, awayTeam == $team, day == $day );
end
[2]
rule startToAwayHop
when
Match($toTeam : homeTeam, $team : awayTeam, $day : day);
not Day($index : index -> ($index.intValue() == $day.getIndex() - 1));
then
assertLogical(new Hop($team, $team, $toTeam));
end
rule homeToAwayHop
when
Match($team : homeTeam, $day1 : day);
Match($toTeam : homeTeam, awayTeam == $team, $day2 : day ->
($day2.getIndex() == $day1.getIndex() + 1));
then
assertLogical(new Hop($team, $team, $toTeam));
end
rule awayToAwayHop
when
Match($fromTeam : homeTeam, $team : awayTeam, $day1 : day);
Match($toTeam : homeTeam, awayTeam == $team, $day2 : day ->
($day2.getIndex() == $day1.getIndex() + 1));
then
assertLogical(new Hop($team, $fromTeam, $toTeam));
end
rule awayToHomeHop
when
Match($fromTeam : homeTeam, $team : awayTeam, $day1 : day);
Match(homeTeam == $team, $day2 : day -> ($day2.getIndex() ==
$day1.getIndex() + 1));
then
assertLogical(new Hop($team, $fromTeam, $team));
end
rule awayToEndHop
when
Match($fromTeam : homeTeam, $team : awayTeam, $day : day);
not Day($index : index -> ($index.intValue() == $day.getIndex() + 1));
then
assertLogical(new Hop($team, $fromTeam, $team));
end
Mark Proctor wrote:
Geoffrey,
In trunk we have a feature called "accumulate", which is also in Jess.
This allows you to execute an action on all matching patterns, the
result is then returned as a bound variable. You can use this feature
to return a collection of matching facts or a calculated value over
those facts, thus a "sum". What we don't do is some form of "delta",
but that sounds very interesting for high volume transactional systems,
not entirely sure how it could be done and it won't make the Q1 release
next year - but if you want to work with us on building thus
functionality into drools, you know where to find us :)
Mark
Geoffrey De Smet wrote:
I am logically asserting a bunch of Routeobjects:
new Route(Object cause, int distance)
and I need the sum of all the distances of all the Routes.
so after the rules are fired I can fetch all Routes and sum the
distances.
Problem is... in my use case I am constantly (like +1k times a second)
changing one little fact, firing all rules and decide which fact to
change next based on the sum of the distances. Talk about stressing
drools's forward-chaining :)
So by constantly recalculating the sum of those distances starting
from 0, it loses a huge amount of scalability.
It would be a lot better if a sum would be calculated like this:
nextSum = lastSum - distanceFromAnyRetractedRoutes +
distanceFromAnyAssertedRoutes;
This would mean that the rules engine would need to support some sort
of sum query's.
What do you think? Is this feasible and in the scope of drools enough
to create a long term feature request in jira for this?
Thanks.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
