On Feb 18, 2009, at 4:28 PM, David Ray wrote:
It is a test I grabbed from one of the tests in the drools package which basically stress tests the rule engine and outputs timing results. I am doing this to compare the total computation time between Drools and Jess - and Jess is about 6 times slower, but I think the problem may not be Jess itself but either how my rules are constructed or some problem where Jess isn't flushing the I/O stream properly.
This program does, indeed, stress-test a rule engine, but it's mostly irrelevant forms of stress, like checking how well your cellphone does under the broiler. I suspect my mostly-plastic phone would do very badly, but my wife's Katana, which I think has an aluminum case, would do better.
There are really two phases: the first is compiling the rules, and the second is running them.
The compiling phase is quite slow. If you think about it, though, raw speed is a poor metric for comparing rule compilation speed, as a rule compiler that does no optimization at all will be much faster than one that does a lot! In this case, the reason Jess is taking so long to compile the 10,000 nearly identical rules is that Jess is looking for opportunities to share nodes in the Rete network. Each rule has a node that checks whether a fact is a RandomNumber fact, with a child that checks the "mod" condition on the value slot. The first node is shared among all rules. The second one, though, is never shared, because the divisor is always different. But Jess checks each new node as it comes in to see if it's a duplicate of a previous one; it has no way to know this will never be the case. Since there are ten thousand of these nodes, the last one that comes in has to be checked against 9,999 others -- i.e., it takes a factorial amount of work to do this check.
The rule compiler is not especially optimized for speed, but in practice, something like this would pretty much never come up. In general, the more time you spend on rule compilation, the less time things take in pattern matching. If you compile the rules just once when the app comes up, and then match against many facts over the uptime of your server, that's of course a win.
Now, the other phase is actually running the rules, and this takes much less time. The program asserts one fact, lets the rules that match it fire, then retracts the fact. As Peter said, this is the business rule engine use case, not exactly the specific use case that Jess is optimized for, which is where a large corpus of data remains in working memory, with a small percentage changing at each cycle. You could indeed get a little speedup here by replacing the Jess-language math in the test CE with a Java function that did the same calculation, but for the most part, you're just measuring the overhead of firing individual rules. As such, when I ran your program I saw many thousands firing per second, which is not bad.
--------------------------------------------------------- Ernest Friedman-Hill Informatics & Decision Sciences, Sandia National Laboratories PO Box 969, MS 9012, Livermore, CA 94550 http://www.jessrules.com -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [email protected]' in the BODY of a message to [email protected], NOT to the list (use your own address!) List problems? Notify [email protected]. --------------------------------------------------------------------
