7:10 p.m.
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!
7:24 p.m.
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(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
12:41 a.m.
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(a)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(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
--
Regards,
Prem
1:54 a.m.
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(a)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(a)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(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
>
--
Regards,
Prem
_______________________________________________
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
2:35 a.m.
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(a)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(a)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(a)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(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
> >
>
>
>
> --
> Regards,
> Prem
> _______________________________________________
> 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
--
Regards,
Prem
3:07 a.m.
Prem,
I understand your concern about == (identity) check agains the equals()
check. However, I think you should first try using the "==" (equals) check
and let the engine index your facts and then, if you still see performance
problems, we look into alternatives. Remember that the identity check will
give you performance gains if you do a lot of comparisons, but with indexed
facts, the actual comparisons will be just a few (possible a single
comparison for each constraint for each rule), so I think the gains will not
be perceptible.
If you were using a predicate to execute the equals() so far, chances are
that you were seing a very poor performance.
Use the regular constraint as we discussed, see the difference and then
we dig deeper if needed.
Now, answering your question, you can't do identity checks in the rules
language without using a predicate or eval to fall back into java code. But,
if you do that, you lose the facts indexing feature.
Send us a sample rule if you are not sure it is written in a way it uses
the engine optimization features and we may try to help you.
Regards
Edson
2007/3/26, Premkumar Stephen <prem18(a)gmail.com>:
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(a)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(a)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(a)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(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
> > >
> >
> >
> >
> > --
> > Regards,
> > Prem
> > _______________________________________________
> > 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
>
>
--
Regards,
Prem
_______________________________________________
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
6240
days inactive
6244
days old
5 comments
2 participants
participants (2)
-
Edson Tirelli -
Premkumar Stephen