[rules-users] Will the alternative lead to a better performance?

Edson Tirelli tirelli at post.com
Mon Mar 26 19:54:19 EDT 2007


   Prem,

   I think you may be misunderstanding something. In DRL language, "==" is
the equals() method. So, if you write a rule:

rule A
when
    UserId( name == "ABC" )
then
    // do something
end

   What the engine will do behind the scenes is name.equals("ABC"). So,
don't be afraid of doing that.

   Also, "huge" means don't worry about it. :) You will get something like
log(n) comparisons in the worst case, so, leave that to the engine.

   []s
   Edson

2007/3/26, Premkumar Stephen <prem18 at gmail.com>:
>
> Hi Edson,
>
> Thanks for your reply.
>
> WRT your reply below (highlighted):
> In our environment, we only have one class and several instances of that
> class.
>
> We currently do not use the "==" constraint and we do a equals() on the
> name string. However, I am going to use "==" since there will be only one
> object with a particular name.
>
> Also, can you define what the number for "huge" is? How many buckets get
> defined initially for the hashing. Can I modify the initial size of this
> collection so that I will not have clashes. ( I happen to know exactly how
> many objects will be thrown into the engine)
>
> Is this set through configuration or would I have to recompile code to do
> this?
>
> Thanks,
> Prem
>
> On 3/23/07, Edson Tirelli < tirelli at post.com> wrote:
> >
> >
> >    Stephen,
> >
> >    As long as you use an "==" constraint as your example shows, the
> > first alternative will be more performatic. This is because drools
> > indexes facts based on your constraints. So, your first case will
> > require a single "==" comparison to find user name "A" and a single
> > comparison to find user name "B". Of course, if you have huge amound of
> > objects where hashcode for name start to clash, you may have more than
> > one comparison, but the effect is negligible when compared to all other
> > costs of having that many facts.
> >
> >    Second alternative works and will also hash object types, but it will
> > create a lot more infrastructure classes and Rete Nodes to deal with
> > your 500 different classes. So it is a worst alternative for the
> > proposed scenario.
> >
> >    []s
> >    Edson
> >
> >
> > Premkumar Stephen wrote:
> >
> > > Hi,
> > >
> > > Consider that I have 500 instances of interface userI. Now, there are
> > > 3000 rules currently written based on a combination of these
> > instances.
> > >
> > > if {
> > >      $a : userI (name = "A")
> > >      $b : userI (name = "B")
> > > }
> > > then
> > > {
> > >  //do some actions
> > > }
> > >
> > > How many tests are needed for a match in the RETE network for this
> > rule?
> > >
> > > If I created 500 classes, one for each object, such as UserA
> > > implements userI and so on... my rule will look like:
> > >
> > > if {
> > >      $a : UserA()
> > >      $b : UserB()
> > > }
> > > then
> > > {
> > >  //do some actions
> > > }
> > >
> > > Will this lead to better performance since there will only be one such
> > > instance of this object?
> > >
> > > As for class-loading concerns, will there be a parsing/memory penalty
> > > to be paid for having 500 classes now instead of one?
> > >
> > > Thanks!
> > >
> >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >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
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
>
>
> --
> Regards,
> Prem
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070326/7191660a/attachment.html 


More information about the rules-users mailing list