[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