The code that generates the rules produces a direct pattern match in the common special case of an equality comparison against a fixed value, and a variable plus constraints in the general case of multiple values or comparisons other than equals. When I modified the code to allow nil, I was unaware that I could use Ernest's syntax below, so I disabled the special-case code and used the variable. It is no problem for me to generate the form that Ernest recommended in the special case, as I don't need the variable for any other purpose. Thanks for the suggestion.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 02, 2008 10:33 AM To: [email protected] Subject: RE: JESS: parse time The first form (R (ProductFamily "campaign_02703"|nil) does not create the variable, which can be an issue if you need that variable defined for a subsequent pattern. What's the effect of the following? (R (ProductFamily "campaign_02703"|nil) (ProductFamily ?ProductFamily)) -Russ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Friedman-Hill Sent: Thursday, October 02, 2008 11:21 AM To: jess-users Subject: Re: JESS: parse time It's probably the "or" that's having the largest impact, but you may be able to reduce the time somewhat by using direct matching yourself -- i.e., just use (R (ProductFamily "campaign_02703"|nil) instead of (R (ProductFamily ?ProductFamily&:(eq ?ProductFamily "campaign_02703")| nil) on the other hand, coding the "or" as a single function call might help, too (you'll have to test both of these and see which is better:) (R (ProductFamily ?ProductFamily&:(or (eq ?ProductFamily "campaign_02703") (eq ?ProductFamily nil))) Note that at runtime all three of these are going to end up in exactly the same form -- it's just the path to get there that may change. On Oct 2, 2008, at 10:28 AM, Adair, John wrote: > Usually for us the tradeoff works out fine, as we create the rulesets > and reuse them over a large number of facts, so the parse time gets > amortized and isn't a problem. Unfortunately in this case the parse > time is dominating the execution time. > > Do you see any easy semantics-preserving things I could do to my rules > to make them more efficiently parseable? Alternatively, can you think > of any changes I could make to the parsing that might help in this > case? > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-jess- > [EMAIL PROTECTED] On Behalf Of Ernest Friedman-Hill > Sent: Wednesday, October 01, 2008 9:58 PM > To: jess-users > Subject: Re: JESS: parse time > > We don't really try to optimize rule compilation time; in general, > time taken to compile rules is supposed to pay off later when they're > used. The function calls in the second form of rule are going to get > expanded and combined, and Jess is going to try to transform them into > direct pattern matches, and a lot of work gets done as Jess figures > out the best way to do it. There's also the simple matter of merging > the rules into a single network, which ultimately comes down to > figuring out if there are duplicate pattern matches across rules; > comparing function-call objects is more expensive than comparing tests > against literals. > > On Oct 1, 2008, at 6:19 PM, Adair, John wrote: > >> Would you expect to see dramatically different parse times for the >> following rules? >> >> (defrule r0 >> (R (ProductFamily "campaign_02703") >> (SKU "2989") >> (_r ?o) >> ) => (?o a (rx)) >> ) >> >> (defrule r0 >> (R (ProductFamily ?ProductFamily&:(eq ?ProductFamily >> "campaign_02703")|nil) >> (SKU ?SKU&:(eq ?SKU "2989")|nil) >> (_r ?o) >> ) => (?o a (rx)) >> ) >> >> For 6,600 rules of the first form, the parse time is below 3 seconds, >> but for the same number of rules of the second form, the parse time >> is above 10 seconds. >> These times are on 7.1, although my investigation was prompted by a >> performance problem in our production app, which is on 7.0, so it >> should be similar there. >> >> >> -------------------------------------------------------------------- >> 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 owner-jess- >> [EMAIL PROTECTED] . >> -------------------------------------------------------------------- > > --------------------------------------------------------- > 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] . > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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] . > -------------------------------------------------------------------- --------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
