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
--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net
