[jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns

[Marc Dzaebel (JIRA)]

    [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020474#comment-13020474 ] 

Marc Dzaebel edited comment on DROOLS-651 at 11/17/14 10:26 AM:
----------------------------------------------------------------

The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: 
{quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster."
{quote} 
So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive.

I don't understand your sentence 
{quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned."
{quote} 
Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change.

Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable.


was (Author: mdzaebel):
The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively caches the results of its matching in between invocations to make it faster.". So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive.

I don't understand the sentence "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned.". Is it possible, to enforce Drools to cache variable bindings?

Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable.

> Duplicate method call inside patterns
> -------------------------------------
>
>                 Key: DROOLS-651
>                 URL: https://issues.jboss.org/browse/DROOLS-651
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.2.0.Beta3
>         Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions)
>            Reporter: Marc Dzaebel
>            Assignee: Mark Proctor
>            Priority: Minor
>
> Create sample Drools project, add following method to the Message class:
> {noformat}   public List<String> list() { 
>       System.out.println("Call!");
>       return Arrays.asList("one", "two"); 
>    } {noformat}
> sample.drl:
> {noformat}
> package com.sample
> import com.sample.DroolsTest.Message;
> import java.util.List;
> import java.util.ArrayList;
>  
> rule ""
>     when m : Message(L : list(), L.size>0)
>     then System.out.println("L:"+L);
> end
> {noformat}
> Running the project will result in the following output:
> {noformat}
> Call!
> Call!
> L:[one, two]
> {noformat}
> So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)