Hi Norman,
There are two things going on if a rule is activated, then
deactivated, then reactivated, etc. First, and usually most important,
there is pattern-matching. If there are a lot of (not) patterns, and
asserting new facts causing old activations to be removed, then this
is because partial matches have to be created and managed to represent
first the activation, then the deactivation. If the facts are asserted
in a different order, fewer partial matches will be created, and the
rule will never be activated in the first place. The manual could
indeed mention this explicitly, although it's really governed by the
same principles as are already discussed.
The other thing that's going on is the agenda management -- i.e., the
keeping and ordering of the list of activated and deactivated
rules. We had a recent discussion about a pathological case where this
could become very slow in currently released versions of Jess, but
it's unlikely to occur in a real system. Generally agenda management
will dominate only when you've got a very large number -- hundreds of
thousands or more -- of activated, but not yet fired, rules. Perhaps
this case -is- coming up for you, but probably not. In any case, I've
recently rewritten the agenda-management code to use a priority queue,
which has much better performance for large agendas. The next Jess
release will include this new code.
I think Gyhra, Norman (Student Assistant) wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi!
>
> I suspect the rule activation / deactiviation mechanism
> gets inefficient if it is extensively used.
>
> I spent lots of time optimizing my rule base so that
> there are no redundant (de)activations.
> I took me quite a long time to find out that they
> are responsible for extraordinarily long fact loading
> times (when rules get activated and deactivated again).
>
> I used (watch all) to get information about superfluous
> activities in the Rete engine. All I needed to do was
> changing the loading order of fact bases and making sure
> that rules fire in a certain order.
>
> Maybe it is worth mentioning this in the "optimization"
> section of the manual.
>
> Regards,
> Norman Gyhra
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
