After a long walk and thinking about shadow facts I think the only way
forward is to remove modify(....) from drl consequences. Modify will
exist external via the WorkingMemory interface, but shadow facts must be
turned on for that class for it to work.
To allow a series of setters for a single propagation to be done in a
drl we must move to one of the following the following syntaxes:
person(name = mark, age = 31)
person.setValues(name = mark, age = 31)
person.(name = mark, age = 31)
Or some variation of the above, we will then use regular expression on
known declarations to turn person(name = mark, age = 31) into :
retract( person, MODIFY ); person.setName( mark ); person.setAge( 31 );
assert( person, MODIFY );
The MODIFYis a keyword to indicate that the propagation is a MODIFICATION
PropertChangeListeners shouldn't have an issue as we can dictate that
they also do a retract and assert, before and after the setting of the
value. Hmm if you are in a consequence and modify a field on a
propertychangelistener fact, you'll need to detect whether the regexp or
the fact handles the retract + assert.
I still have plans to "weave" facts to allow them to seamlessly handle
modifies, I had a mock up implementation for this (uncommitted) and lost
it when I sent my laptop back to dell, forget to back it up :( Still
shouldn't take long to remake that.
Mark Proctor wrote:
I think it will be hard. My preference is to change the drl to do a
retract+assert on a modify, that way we don't need shadow facts - as
long as they keep the modifies strictly inside the drl - which I think
is fair.
Mark
Edson Tirelli wrote:
Mark,
I can tell you for sure that the overhead is not linear. It is
worst then that.
For that user asserting up to 1million facts, as the rules have
just a few partial matches, the overhead makes the performance be
worst than 3.0.x branch.
One question and one comment:
Comment: I still don't like the design of current proxy. As you
remember, we do lazy proxy, but equals/hashcode methods had to be
overriden to avoid strange behavior and they now call proxy methods
to get the values to compare. It means, even being lazy, once
anything in the engine call hashcode/equals methods, it will load all
attributes into the proxy. It basically removes any benefit of being
lazy.
Question: how easy do you think we can do binding/constraint
analyzis, in order to: 1) automatically disable shadow facts for
facts that do not change bound/constrained attributes and 2) maybe
limit the proxy caching to only those methods?
Just brainstorming here...
[]s
Edson
Mark Proctor wrote:
I'm finding that in manners shadow facts add on average about 10% or
under to execution times.
test by changing:
count.setValue( count.getValue() + 1 ); modify( count );
To (with shadow facts turned off)
retract( count );
count.setValue( count.getValue() + 1 ); assert( count );
The problem I'm having is finding a generic and clean way to make
shadow facts configurable and have the .drl adapt appropriately,
without the user having to manually do retract and asserts, instead
of a modify.
Having had feedback from users that are asserting a huge number of
facts (approx 1mill) into the working memory, having the ability to
not deal with shadowfacts will improve performance and memory, more
so than in the case of manners. I'd be interested ot know if the 10%
or less rule is still true with those large numbers, and also the
size in memory.
Mark
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
