Drools is an extremely fast rule engine.
Under the hood, OptaPlanner has used Drools as a score engine for ages.
Today, we’re announcing a faster, lightweight alternative: Bavet.
Bavet is a feature of OptaPlanner. It is not a rule engine.
It is a pure, single-purpose, incremental score calculation implementation
of the ConstraintStreams API.
Bavet is feature complete as of OptaPlanner
You can switch from Drools to Bavet in a single line of code.
Twice as fast score calculation. Zero API changes.
For 20 diverse use cases, we compared Bavet and Drools for OptaPlanner score calculation.
We ran JMH benchmarks
on OpenJDK 17 (
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:
|Use case||Drools||Bavet||Speed up|
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.
Not a rule engine
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
But below the surface, it’s a very different implementation.
Compare it with the method signatures of similar methods in the JoinNode in Drools.
History and naming
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
On the OptaPlanner hello-world quickstart,
a Maven assembly of
jar-with-dependencies with only Bavet included is
10 MB smaller:
|Core dependencies||Size||Reduction||Core exclusions|
Drools CS only
Bavet CS only
optaplanner-core includes both Drools and Bavet,
so you have to explicitly exclude it in Maven or Gradle:
org.optaplanner optaplanner-core org.optaplanner optaplanner-constraint-drl org.optaplanner optaplanner-constraint-streams-drools
optaplanner-core from 42 to 17 transitive dependencies.
Specifically, all these jars are removed from your classpath:
- org.optaplanner:optaplanner-constraint-streams-drools:... +- org.drools:drools-engine:... | +- org.kie:kie-api:... | +- org.kie:kie-internal:... | +- org.drools:drools-core:... | | +- org.kie:kie-util-xml:... | | +- org.drools:drools-wiring-api:... | | +- org.drools:drools-wiring-static:... | | +- org.drools:drools-util:... | | - commons-codec:commons-codec:... | +- org.drools:drools-wiring-dynamic:... | +- org.drools:drools-kiesession:... | +- org.drools:drools-tms:... | +- org.drools:drools-compiler:... | | +- org.drools:drools-drl-parser:... | | +- org.drools:drools-drl-extensions:... | | +- org.drools:drools-drl-ast:... | | +- org.kie:kie-memory-compiler:... | | +- org.drools:drools-ecj:... | | +- org.kie:kie-util-maven-support:... | | - org.antlr:antlr-runtime:... | +- org.drools:drools-model-compiler:... | | - org.drools:drools-canonical-model:... | - org.drools:drools-model-codegen:... | +- org.drools:drools-codegen-common:... | +- com.github.javaparser:javaparser-core:... | +- org.drools:drools-mvel-parser:... | - org.drools:drools-mvel-compiler:... - org.drools:drools-alphanetwork-compiler:...
optaplanner-constraint-streams-bavet) has no transitive dependencies
Try it out
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
Switch to Bavet in either your
solverFactory = SolverFactory.create(new SolverConfig() ... .withConstraintStreamImplType(ConstraintStreamImplType.BAVET) ...);
or in your
Switch to Bavet in
Switch to Bavet in
Share your results
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.
Red Hat support
A Red Hat support subscription will not offer support for Bavet.
Drools intends to catch up performance wise.