I think =?iso-8859-4?Q?Raoul_J=E4rvis?= wrote:
[Charset iso-8859-4 unsupported, filtering to ASCII...]
> Hello,
>
> I was wondering about the possibilities of speeding up the matching process.
This is micro-optimization; not worth the effort. Algorithmic
improvements are generally more fruitful. Note, by the way, that
Jess's performance is excellent compared to other commercial rule
engines.
>
> The type of data values (as declared in deftemplate) used in the
> patterns should also be significant (e.g. Integer matching should be
> faster than string matching),
It is, see below.
> but the Jess manual states that "The 'type' slot qualifier is
> accepted but not currently enforced by Jess; it specifies what data
> type the slot is allowed to hold."
>
> What does it mean to be "not enforced"?
It means that by default, Jess doesn't use it for anything, so that a
slot can hold any data type. But Jess does keep data as typed
information, and that type info is indeed used during matching. It's
just that the type of the data held in a specific slot is not
restricted.
Restricting slots to hold only one type would be worthless unless you
were generating new Java classes to hold each kind of fact, with typed
member variables to hold each slot. Although this is something we've
considered as an option, it's meager benefits are far outweighed by
the drawbacks (for example, rule compilation time would go through the
roof, as would total code size -- the processor-cache issues alone
would probably actually slow things down.)
> Does it mean that internally
> the matching is done with values of some custom type?
Both the manual and the book go into some detail about the jess.Value
class which is used to represent individual data.
Or, when I define
> (deftemplate state (slot status (TYPE INTEGER)) etc.)
> and
> (defrule action
> ?f <- (state (status 2) ...)
> ...etc.
> then the matching process compares two integers instead of something else.
Matching already will compare two integers, by a call to
Value.equals(). Have a look at the source in jess/Value.java:
public boolean equals(Value v) {
if (this == v)
return true;
if (v.m_type != m_type)
return false;
switch (m_type) {
case RU.INTEGER:
case RU.FACT:
return (m_intval == v.m_intval);
case RU.FLOAT:
return (m_floatval == v.m_floatval);
default:
return m_objectval.equals(v.m_objectval);
}
}
So matching two integers currently requires one pointer comparison,
and two member (int) comparisions. You could theoretically reduce
that, but this small amount of computation is already swamped by other
overhead.
There is a class of problems where fixed slot types DOES have a
performance advantage: problems like examples/wordgame.clp where there
is a LOT of math on the LHS of a rule (not like single "+" function
calls, but (+ (+ (*) (-) (+ (*) (+)))) kind of stuff). If a slot holds
a fixed data type, then it's possible to compile the math expressions
into Java classes. I've had an experimental implementation of this for
a long time, and can share it on request with people who have a source
license. My version handles only a few functions.
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems 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]
--------------------------------------------------------------------
