RE: [rules-users] field binding performance implications
by Olenin, Vladimir (MOH)
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(a)lists.jboss.org
[mailto:rules-users-bounces@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(a)lists.jboss.org
>[mailto:rules-users-bounces@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(a)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
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
