I think Timothy Redmond wrote: > - Is there a good Jess rule profiler (as opposed to a java profiler)?
There will be tools in Charlemagne for exploring performance issues. Right now using the "view" command, or its non-graphical equivalent the "matches" command, can give you an idea where things might be going wrong. > > - Are shadow facts expensive, particularly if many of the fields in > the shadow fact are not needed by Jess? > No, not really; see below. > - Alternatively, is template inheritance expensive? (We only have > inheritance for the shadow facts.) > > - Is 30ms per definstance good performance? > No, it's not. My standard benchmark is the JButton. Defclassing javax.swing.JButton gets you a template with 89 slots. On my current machine (2.4GHz P4, JDK 1.4.2) you can definstance about 100,000 of these (each with a different integer as its "text" property) in one minute with no rules, or just a few simple rules, defined. (For comparison purposes, a pure Java program can create 100,000 numbered JButtons and store them in a HashMap by index in about 10 seconds; a Jess program that does the same takes just 15 seconds.) Now, if we start adding rules, what happens? A rule like (defrule example-1 ;; Match every button (button) => ) adds essentially no time to this one minute. More complex rules add a few seconds: (defrule example-2 ;; Match every even-numbered button (button (text ?t&:(evenp (integer ?t)))) =>) You can even compare facts to one another without it being too expensive. This rule, again, takes negligible time: (defrule example-3 ;; Match two different buttons with the same label (button (text ?t) (OBJECT ?o)) (button (text ?t) (OBJECT ~?o)) => ) These patterns are fast because they only use the built-in matching operators; Jess can evaluate these matches very quickly. Rules that compare facts to one another can start to get expensive, though, depending on what they have to do. A rule like this one, which compares every fact to, on the average, half of all other facts, slows things down a lot. The first 1000 JButtons take 6 seconds; the next 1000 take 16, and the next 1000 take 24, and so on. Because of the function call, Jess can't use any fancy indexing to reduce the number of comparisons. The full 100,000 would take a few hours. (defrule example-4 ;; Find the pairs of buttons such that one's label is one greater ;; then the other (button (text ?t1)) (unique (button (text ?t2&=(str-cat (+ (integer ?t1) 1))))) => But it's actually possible to write example-4 in an even less efficient way (using the "test" CE is very often a good way to write things less efficiently.) (defrule example-5 ;; Find the pairs of buttons such that one's label is one greater ;; then the other, inefficiently (button (text ?t1)) (button (text ?t2)) (test (eq ?t2 (str-cat (+ (integer ?t1) 1)))) => ) In this form, all possible pairs of button facts are formed, and then the excess ones are weeded out. This takes about 50% longer to run. But it's not that function calls are bad or slow, or that more tests make things slower. Indeed, here's a similar rule that's much faster: (defrule example-6 ;; Find the pairs of buttons such that one's label is one greater ;; then the other, and the first number starts with the digits "210" (button (text ?t1&:(?t1 startsWith "210")) (button (text ?t2)) (test (eq ?t2 (str-cat (+ (integer ?t1) 1)))) => ) On my machine, this rule can process 100,000 JButtons in about 2 minutes, 15 seconds; about 1 millisecond each. This is fast because the first pattern is very specific. > - Are there guidelines on what type of performance we can expect in > running the inference engine over these facts? We are figuring on the > order of a couple of hundred rules that will fire100s of thousands of > times. > Remember that, as you're seeing, all the computational work of pattern matching is done while facts are being created, removed, or modified. The time taken by actually firing rules is generally negligible. > - Is there a way to use focus and the module concept to improve > performance (only some of the rules are activated at a time)? No, that won't affect performance. > - Is there a sequence that is particularly effective (e.g. assert the > facts and then introduce the rules?) Defining the rules first and then populating working memory is a little faster than doing things in reverse. --------------------------------------------------------- Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- 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] --------------------------------------------------------------------
