I've tried to reproduce this in a tester but all my unit tests show 6.0.0
marginally quicker. The rules and data are simplified for the test so I'll
try something closer to what i am seeing on the full system. I've just done
another comparison and the results are shown in the attached image.
Are you able to provide a test, for something that produces this?
Mark
On 28 Jan 2014, at 10:58, pmander paul.s.man...@gmail.com wrote:
I've tried to reproduce this in a tester but all my unit tests show 6.0.0
marginally quicker. The rules and data are simplified for the test so I'll
try
please do pop onto irc and provides us with more details on the performance
testing you are doing. We need to add more tests to our test suite, to
track any regressions.
http://www.jboss.org/drools/irc
Mark
On 23 Jan 2014, at 15:11, pmander paul.s.man...@gmail.com wrote:
Thanks,
This was just
Mark Proctor wrote
Also there will be no performance games for rule bases that do not have
joins
Can you elaborate on what a join is?
--
View this message in context:
http://drools.46999.n3.nabble.com/java-dialect-and-declared-types-tp4027822p4027871.html
Sent from the Drools: User forum
a join is any rule that has more than one pattern. Each pattern after the
first, causes an additional join node in the network.
Mark
On 27 Jan 2014, at 16:55, pmander paul.s.man...@gmail.com wrote:
Mark Proctor wrote
Also there will be no performance games for rule bases that do not have
If I declare a type in a drl and reference the attributes in a rule then all
is fine for either dialect. But, if one of the attributes is a java class
that has been compiled and inserted then under the java dialect only I get a
compilation error: rule compilation error the field ... is not visible
Declared types have public accessors as usual.
This seems a minor bug in the expression analysis.
Can you try
getRaw().complicated()
and / or
raw.complicated
and report what happens?
Thanks
Davide
On 01/23/2014 06:40 AM, pmander wrote:
If I declare a type in a drl and reference the
will do, although complicated() has parameters and so I think I'll only able
to try getRaw.complicated()
--
View this message in context:
http://drools.46999.n3.nabble.com/java-dialect-and-declared-types-tp4027822p4027825.html
Sent from the Drools: User forum mailing list archive at
In that case I'm almost sure that the whole constraint has to be treated
as a java expression.
So yes, you will probably need getRaw().complicated( ... )
On 01/23/2014 08:06 AM, pmander wrote:
will do, although complicated() has parameters and so I think I'll only able
to try
Yes, if you use the java dialect, the whole RHS is parsed as a java block
with some minor syntactic sugar (e.g. insert).
On 01/23/2014 08:46 AM, pmander wrote:
Davide Sottara wrote
Declared types have public accessors as usual.
This seems a minor bug in the expression analysis.
Can you try
please do pop onto irc and provides us with more details on the performance
testing you are doing. We need to add more tests to our test suite, to track
any regressions.
http://www.jboss.org/drools/irc
Mark
On 23 Jan 2014, at 15:11, pmander paul.s.man...@gmail.com wrote:
Thanks,
This was
Hi,
I'd like to reproduce and verify your performance claims.
If you found a performance regression it would be very interesting for me to
investigate it.
Could you please send a small self-contained project with the benchmarks you
tried?
Personally I believe that The tests also show that
I should qualify this with the way that we are using drools. In general
perhaps 6 is quicker that 5.5. It will be extremely difficult to create a
self contained test to demonstrate this as the tests are performed with tens
of millions of transactions against ten of thousands of rules.
I will
13 matches
Mail list logo
