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

[Premkumar Stephen]

Thanks Edson for clarifying that in DRL, the "==" is the equals() method.
However, as this is not the case with java, can I tell the engine that "=="
means "==" and not "equals()"?

While the "equals()" will not return a wrong value, in my case, it might be
more expensive than "=="

Regards,
Prem


On 3/26/07, Edson Tirelli <tirelli at post.com> wrote:
>
>
>    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
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
Regards,
Prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070326/c93d9cf0/attachment.html