Ultimately, of course, a Fact is an array, with one element for each slot. When you compile a rule, the rule compiler will look up the names of any slots that are mentioned, and it's the index of the slot that gets compiled into the rule.
On the other hand, fact-slot-value is a function that has to look up the index of a slot by name at runtime. The lookup is fast, as it's an O(1) HashMap lookup, but still, it represents a finite amount of overhead. So in other words. (defrule fast-rule (foo (bar ?x)) => (printout t ?x crlf)) represents much less computation than (defrule slow-rule ?f <- (foo) => (printout t (fact-slot-value ?f bar) crlf)) So that's one case. It's just a little bad. The other case is calling fact-slot-value on the LHS of a rule, which can be *devestatingly* bad. If you use fact-slot-value on the LHS of a rule, you hide important information from the rule compiler -- namely, what parts of a fact are interesting in a given rule. The rule compiler will use this information to index the Rete memories. If there's no information, then the relevant node memories default to flat lists and linear lookups, which can be very slow. So, for example, this rule is fast, (defrule fast-rule-2 (foo (bar ?x)) (bar (foo ?x)) => (printout t "Found a match!" crlf)) While this one is terrible (assuming large numbers of foo and bar facts, of course:) (defrule slow-rule-2 ?f <- (foo) ?b <-(bar) (test (eq (fact-slot-value ?f bar) (fact-slot-value ?b foo))) => (printout t "Found a match!" crlf)) But actually, this one may be just as bad: (defrule slow-rule-3 (foo (bar ?x)) (bar (foo ?y)) (test (eq ?x ?y)) => (printout t "Found a match!" crlf)) as might this one (which surprises a lot of people): (defrule slow-rule-4 (foo (bar ?x)) (bar (foo ?y&:(eq ?x ?y))) => (printout t "Found a match!" crlf)) I say "might be" because Jess tries to do the right thing for these, but can't always do so. In any case, direct matching (including direct negated matches using "~") is always vastly faster than calling a function on the LHS of a rule. I think Jon Weygandt wrote: > > Ernest, > > Thanks for your description of locks, the part of values and bindings > and "fact-slot-value" references are of interest. > > I have 2 cases where rules use the "fact-slot-value" method, and based > upon the original postings multithreaded use case, are these uses thread > safe or could the value of the fact change from the original match to > the access of slot data. > > My specific task is to improve the throughput of the application and as > I have inherited these rules from another source, I would also be > curious as to your thoughts on the performance of fact-slot-value vs. > the early binding of all the necessary values in the original rule > pattern. The matching test for the rules may involve as few as 2-4 > fields, whereas the "some-function" and access to the fields may be as > many as 10 fields. > > Case 1 (fact-slot-value in rhs) > (defrule r1 > ?f1 <- > (FACT1 > (OP "UPDATE") > ... > ) > ... > => > ... > (some-function (fact-slot-value ?f1 S1)) > ) > > Case 2 (fact-slot-value in lhs) > (defrule r1 > ?f1 <- > (FACT1 > (OP "UPDATE") > ... > ) > (exists > (or > (test (neq (fact-slot-value ?eqpst S1) > (fact-slot-value ?eqpst S2))) > (test (neq (fact-slot-value ?eqpst S3) > (fact-slot-value ?eqpst S4))) > ) > ) > ... > => > ... > ) > > Thanks, > Jon Weygandt > > -- Original Message -- > > > If one thread is executing run() (and fires and executes rules) and a > > second threads does a deffact() or undeffact(), can the facts be > updated > > while a RHS is executing? > > There is no "deffact()" method, but based on your earlier statements I > think you mean "definstance()". Can facts be updated while a rule is > firing? Yes. Values bound on the LHS are copies from the facts that > activate a rule before the rule fires, so if the fact changes while > the rule is firing, the original bound values are used. > > > -------------------------------------------------------------------- > 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 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] --------------------------------------------------------------------
