KIE Community

For 20 diverse use cases, we compared Bavet and Drools for OptaPlanner score calculation.
We ran JMH benchmarks
on OpenJDK 17 (ParallelGC, Xmx1G)
on a stable benchmark machine (Intel® Xeon® Silver (12 cores total / 24 threads) and 128 GiB RAM memory)
without any other computational demanding processes running.

On average, Bavet is twice as fast as Drools for score calculation.
In the Vehicle Routing Problem,
Bavet is even three times as fast as Drools:

Bavet is faster than Drools for 90% of the use cases.
Of course, your mileage may vary.
Turn on Bavet and if it’s not faster in your use case, let us know.

Drools and Bavet are both still improving.
This performance race is far from over.

Does Bavet scale well?

On commodity hardware, we ran a 5 minutes VRP benchmark on different dataset sizes,
to compare how Drools and Bavet scale up:

Same story, but the performance gap does close as the scale goes up.

Bavet is not a rule engine.
It deliberately doesn’t support inference, nor Complex Event Processing (CEP),
nor other common business rule engine features:

OptaPlanner only requires a score engine.
Its Drools implementation only uses a small subset of Drools’s features.
Bavet on the other hand, is a score engine tailored to OptaPlanner.
It’s part of OptaPlanner. It has no use outside of OptaPlanner.

For incremental score calculation, Bavet borrows techniques from the RETE algorithm
and Drools’s Phreak algorithm.
For example, the JoinNode in Bavet
contains insert(), update() and retract() methods.
But below the surface, it’s a very different implementation.
Compare it with the method signatures of similar methods in the JoinNode in Drools.

I created Bavet as a POC in 2019
and added it into OptaPlanner as an experimental, fast, incomplete feature.
There it sat frozen. For 3 years.
Until recently, when Lukáš Petrovický and me completed all missing features
and refactored it to the performance sensation is today.

Naming wise, bavet is a Flemish (Dutch) slang word for a bib.
Very useful if your baby is drooling.
I came up with that name when we were eating with our kids at a spaghetti restaurant called Bavet,
while facing this mural:

Ok, maybe I didn’t put much effort into that.

But it doesn’t really need a good name.
It’s just one of OptaPlanner’s score calculation options.
An implementation detail, really.

We believe Bavet is very stable.
We successfully run our 48+ hours stress tests on Bavet regularly.
These stress tests stomp out score corruption by solving a lot of datasets across many use cases.

In OpenShift and Kubernetes clouds, the size of pods matter.
By using Bavet, you can slim down OptaPlanner’s classpath
to exclude the Drools dependencies.
The Bavet jar is 400 KB.

On the OptaPlanner hello-world quickstart,
a Maven assembly of jar-with-dependencies with only Bavet included is 10 MB smaller:

By default, optaplanner-core includes both Drools and Bavet,
so you have to explicitly exclude it in Maven or Gradle:

This reduces optaplanner-core from 42 to 17 transitive dependencies.
Specifically, all these jars are removed from your classpath:

Bavet (optaplanner-constraint-streams-bavet) has no transitive dependencies
(except for optaplanner-constraint-streams-common).

First upgrade to OptaPlanner 8.27.0.Final or later, if you haven’t already.
If you’re using the deprecated scoreDRL approach, migrate from scoreDRL to constraint streams first.

By default, OptaPlanner still uses Drools for constraint streams.
To use Bavet instead, explicitly switch the ConstraintStreamImplType to BAVET:

Help us out. Try Bavet and let us know here
how your score calculation speed changes.
Look for the score calculation speed in the INFO log: it’s part of the Solving ended message.

A Red Hat support subscription will not offer support for Bavet.
Drools intends to catch up performance wise.