[rules-dev] Shadow Facts
Mark Proctor
mproctor at codehaus.org
Sun Feb 11 08:54:30 EST 2007
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
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
More information about the rules-dev
mailing list