[rules-users] field binding performance implications

[Edson Tirelli]

   Probably I misinterpreted you. :)

   You are saying you want the ability to change the templates in order 
to generate different rules? If so, probably better to keep template 
based generating DRL.
   I thought you would have a GUI application for the user to define 
your rules with pre-defined templates... in that case, using descriptors 
would sabe you the parsing time.
   But not really a big difference. So, go with templates and use the 
parser. No problem in doing that.

   []s
   Edson

Olenin, Vladimir (MOH) wrote:

>I see. The problem though is the logic and 'rule composition' is different
>for each group of rules and is NOT data driven (client doesn't want the
>logic to be present in the input data). From what I understand generating
>descriptors directly would make me define the logic inside the 'parser' or
>at the very least somewhere in Java code, unless I opt out for a separate
>text format to describe 'just' the logic. But it seems like it'd be more
>complicated than generating drl file directly...
>
>Thanks for the suggestion though - I'll think it over again - probably I've
>just misinterpreted you...
>
>Vlad
> 
>
>-----Original Message-----
>From: rules-users-bounces at lists.jboss.org
>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Edson Tirelli
>Sent: 21 March 2007 19:17
>To: Rules Users List
>Subject: Re: [rules-users] field binding performance implications
>
>
>   Vlad,
>
>   Looking at the macro steps, when you load and run rules in the 
>engine, that is what happens:
>
>* PARSING: a parser, will parse whatever syntax you are using into an 
>AST tree. The objects that compound that tree are the descriptors I'm 
>talking about.
>* BUILDING: a rule builder will transform your descriptors (AST Tree) 
>into the internal rules representation, doing all the code generation 
>and compiling it into binary form.
>* RETE-BUILDING: a ReteOO builder will get your compiled rules 
>representation and transform into a Rete network, making it ready for 
>execution
>
>    So, basically, descriptors are the result of the parsing. If you are 
>generating rules, better to skip the parsing phase and generate 
>descriptors directly. Also, we aim to have full round-trip between 
>supported semantics. That means that from the descriptors, you can 
>generate DRL, XML, CLP, or whatever syntax you have a dumper for.
>
>    Having said all that, you can find the descriptors in the package: 
>org.drools.lang.descr in the drools-compiler project. Documentation is 
>not good (any volunteers? :)), but they are pretty simple to use, so you 
>will have no problems understanding them. Also, if you don't know how to 
>represent something using descriptors, it is easy to find out. Just 
>write a DRL that does what you want to know how and use the package 
>builder to get the descriptors for you to see:
>
>        DrlParser parser = new DrlParser();
>        final PackageDescr pkgDescr = parser.parse( new 
>InputStreamReader( getClass().getResourceAsStream( "test_rules.drl" ) ) );
>
>   Hope it helps.
>
>   []s
>   Edson
>
>
>Olenin, Vladimir (MOH) wrote:
>
>  
>
>>Hmm... Descriptors? What is this?
>>
>>-----Original Message-----
>>From: rules-users-bounces at lists.jboss.org
>>[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Edson Tirelli
>>Sent: 21 March 2007 16:47
>>To: Rules Users List
>>Subject: Re: [rules-users] field binding performance implications
>>
>> Vlad,
>>
>>Didn't tested myself, but I don't see a reason for performance impacts 
>>adding unneeded declarations, except for consuming a bit more of memory, 
>>but I would say would be negligible in the numbers you provided.
>>Although, may I suggest that you generate Descriptors instead of DRL? 
>>This will give you gains in parsing time (as there will not be parsing), 
>>besides being easier than using string templates IMO. Also, if you want 
>>to store a "text" based version of your rules, you can simply use a 
>>dumper to dump wherever syntax you prefer.
>>
>>[]s
>>Edson
>>
>>
>>
>>Olenin, Vladimir (MOH) wrote:
>>
>> 
>>
>>    
>>
>>>Hi,
>>>
>>>We need to generate drl file from a template. Since the format of the 
>>>rules parameters doesn't fall very well within decision table concept 
>>>(the parameters are not 'homogeneous', so each row in the input excel 
>>>table can mean different things), we decided to define the rules by 
>>>automatically generating drl files from a set of templates. To cover 
>>>more cases with a single template we'd need to bind every field of 
>>>column by default, even if the binding would not be used.
>>>
>>>For example (Freemarker syntax is used in the template below):
>>>
>>>Rule ${ruleId}
>>>
>>>When
>>>
>>>Record ( $account : account ${operation} ${value} )
>>>
>>>....
>>>
>>>Then
>>>
>>>.....
>>>
>>>End
>>>
>>>In the example above, 'operation', 'value' and 'ruleId' are objects in 
>>>the data model that we merge with the template. One case of the rule 
>>>would be when both 'operation' and 'value' are empty strings. This 
>>>will result in this LHS: Record ( $account : account ). Another case 
>>>might be when 'operation' is '==' string and 'value' is '1': Record ( 
>>>$account : account == 1 ).
>>>
>>>The above is a simplified template to demonstrate the point. The real 
>>>business data model for facts (Record object) would have around 10 
>>>fields and we can have ~ 5 to 10 columns per rule. I wonder what kind 
>>>of performance implications does field binding bring? Are there any or 
>>>this is being optimized / filtered out by some preprocessor?
>>>
>>>In other words, is there significant difference in performance for the 
>>>following LHS expressions:
>>>
>>>1) Record ( $account : account, $name : name == 'xxx', $balance : 
>>>balance > 100, ....)
>>>
>>>Vs
>>>
>>>2) Record (name == 'xxx', balance > 100, ....)
>>>
>>>Providing the functionality of both of these LHS expressions is the 
>>>same and field bindings in LHS #1 are never used throughout the rule.
>>>
>>>Thanks,
>>>
>>>Vlad
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>rules-users mailing list
>>>rules-users at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>
>  
>


-- 
 Edson Tirelli
 Software Engineer - JBoss Rules Core Developer
 Office: +55 11 3124-6000
 Mobile: +55 11 9218-4151
 JBoss, a division of Red Hat @ www.jboss.com