Re: [rules-dev] Shadow Facts
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>