eclipse-viatra-bot
commented
4 months ago By Abel Hegedus on Jan 26, 2018 04:26
Note that conflict set implementation can be overridden by the user (by setting a different ConflictResolver on the rule engine).
If you could provide example code and measurement results, comparing the built-in implementations with a different conflict set implementation that behaves better under such load, that would be very useful.
Gabor mentioned that in Rete a similar problem was solved by instantiating a new set when the capacity/size ratio becomes too large.
| --- | --- | | Bugzilla Link | 530057 | | Status | NEW | | Importance | P3 enhancement | | Reported | Jan 19, 2018 14:55 EDT | | Modified | May 27, 2019 07:45 EDT | | Version | 1.7.0 | | Blocks | 398765 | | Reporter | Gabor Bergmann |
Description
Kristóf Marussy has reported observing a quadratic degradation of rule engine performance in the number of rules used.
When first a great number of rule activations are found, the agenda / conflict set will grow into a large hash set. Then as rules are fired off one by one, the head of the hash set is found repeatedly using iterator.next(). As the conflict set is becoming nearly empty towards the end of the transformation run, the hash set supposedly retains its largest extent, but actual occupying entries are only found scarcely, thus making iterator.next() a linear operation for each call.
This anecdotal claim should be demonstrated and investigated. A similar phenomenon might also occur in Rete mailboxes.