With the release of Java 21 just around the corner, you may be wondering how it compares to Java 17 and whether you should upgrade. Here at Timefold, so were we. Read on to find out how Timefold Solver performs on Java 21, compared to Java 17.

But first, let’s get some things out of the way.

What is Java 21 and how to get it

Java 21 is a new release of the Java platform, the trusty programming language that Timefold Solver is written in. It brings a bunch of new features, as well as the usual bugfixes and smaller improvements.

Java 21 will be generally available on September 19, 2023, but you can already try it out using the release candidate builds. We find that the easiest way to get started with Java 21 is to use SDKMAN, and that is what did as well. (See the end of this post for the specific versions and hardware used.)

Like Java 17 before it, Java 21 is a long-term support (LTS) release; it will stick around for quite a while. It is therefore a good idea to start using it as soon as possible and see if it works for you.

For Timefold Solver, that means making sure the entire codebase continues to work flawlessly on Java 21, as well as running some benchmarks to ensure our users can expect at least the same performance as before. Let’s get started on that.

Micro-benchmarks

We’ll start with score director micro-benchmarks, which we use regularly to establish the impact of various changes on the performance of Constraint Streams. These benchmarks do not run the entire solver; rather, they focus exclusively on the score calculation part of the solver.

They are implemented using Java Microbenchmark Harness (JMH), and they run in many Java Virtual Machine (JVM) forks and with sufficient warmup. This gives us a good level of confidence in the results. In fact, the margin of error on these numbers is only ± 2%.

Here is the Constraint Streams performance on Java 21 vs. Java 17:

Most cases show a small performance improvement when switching to Java 21. The "Conference Scheduling" benchmark is the only outlier, and with some extra work on the solver we can likely get the performance of that benchmark to improve as well.

It should be noted that we ran these benchmarks with ParallelGC as the garbage collector (GC), instead of the default G1GC. Later in this post we’ll explain why.

Real-world benchmarks

Now that we’ve seen the micro-benchmarks, it’s time to compare them to real-world solver performance. This includes the entire solver, not just the score calculation part.

We ran the solver manually in 10 different JVM forks, and used the median score calculation speed. We selected a subset of the available benchmarks, to keep the run time short; the selection is representative of the entire benchmark suite in terms of heuristics used and code paths exercised. Once again, ParallelGC is used as the garbage collector. Here are the results:

There are no surprises here. We see small performance improvements across the board, confirming the results of the micro-benchmarks. Compared to the micro-benchmarks, "Conference Scheduling" no longer registers as an outlier, which is interesting and will serve as another data point in our investigation into that possible regression.

Since we haven’t established a formal interval of confidence for these large benchmarks, we can’t say with certainty that the improvements are statistically significant. However, the fluctuations observed between runs have been small enough to give us confidence in the results.

Why ParallelGC?

In the years that we’ve been working with the Timefold Solver and its predecessor, OptaPlanner, we’ve found that ParallelGC is the best garbage collector for the solver. This should not be surprising - ParallelGC is tailored for high throughput, and the solver is 100 % CPU-bound. G1GC (the default garbage collector) is instead tailored for low latency, and that makes a considerable difference. However, things change and we occasionally need to challenge our assumptions. Is ParallelGC still the best GC for the solver?

The following chart shows the difference in performance between G1GC (the baseline) and ParallelGC. And since Java 21 introduced generational ZGC, another GC aiming for low latency, we thought it would be interesting to include that as well.

The results (obtained by the micro-benchmarks from earlier) are clear:

• ParallelGC continues to be the best GC for the solver.
• G1GC comes second, but it’s considerably slower.
• ZGC is by far the worst of the three.

The situation may change if we increased the heap size available to the JVM as ParallelGC does not scale well with large heaps, but with -Xmx1G, it is the clear winner. (And 1GB of heap is more than enough for many use cases of Timefold Solver.)

Conclusion

In this post, we’ve shown that:

• Timefold Solver 1.1.0 works perfectly fine with Java 21, no changes are needed.
• Switching to Java 21 may bring a small performance improvement to your Timefold Solver application, but your mileage may vary slightly.
• ParallelGC continues to be the best garbage collector for the solver.

We encourage you to try Java 21 and make the switch. It is free after all, and you’ll be able to enjoy the latest and greatest Java platform.

Appendix A: Reproducing the results

These benchmarks use Timefold Solver 1.1.0, the latest version at the time of writing.

All benchmarks were run on Fedora Linux 38, with Intel Core i7-12700H CPU and 32 GB of RAM. We used OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7) (available as 17.0.8-tem on SDKMAN) and OpenJDK Runtime Environment (build 21+35-2513) (available as 21.ea.35-open on SDKMAN).

Source code of the micro-benchmarks can be found in my own personal repository. The real-world benchmarks were run using timefold-solver-benchmark, this configuration and a simple script. (You’ll need timefold-solver-examples on the classpath.) All data used for the charts can be found in this spreadsheet.

The vehicle routing problem (VRP) is a popular academic optimization problem with numerous variants.

While you can map the vehicle routing problem to real-world tasks like planning deliveries or optimizing itineraries for field service technicians, very often you have to deal with at least one additional constraint: customers' availabilities.

This post will show you how to solve the vehicle routing problem using Timefold Solver.

VRP with time windows

Let’s start by defining the problem. Same as the vanilla VRP, the task is to plan routes of N vehicles to visit M customers to minimize the driving time. The additional complexity comes from customers' availability in limited time windows. If the vehicle arrives at the destination too early, it has to wait, which is suboptimal. If it arrives too late, it’s even worse as the planned visit has to be rescheduled to some other day and all the mileage driven comes in vain.

Domain model

The domain model takes advantage of the @PlanningListVariable: the Vehicle is the @PlanningEntity with a list of Customer instances to visit. The @PlanningListVariable enables the use of a few build-in shadow variables:

• @InverseRelationShadowVariable that points from the Customer to the assigned Vehicle.
• @PreviousElementShadowVariable and @NextElementShadowVariable that point to the previous and the next customer in the list respectively.

To calculate the arrival time at each customer, the model relies on the arrivalTimeshadow variable that is updated by the ArrivalTimeUpdatingVariableListener every time the previousCustomer or the vehicle changes.

Constraints

The constraints are implemented using the Constraint Streams API and you can see them in the VehicleRoutingConstraintProvider.java.

Service must be finished in time

Providing the service to the customer also takes time, expressed by the serviceDuration. Of course, the service duration counts towards the customer’s availability. This is a hard constraint.

protected Constraint serviceFinishedAfterDueTime(ConstraintFactory factory) {
   return factory.forEach(Customer.class)
           .filter(Customer::isServiceFinishedAfterDueTime)
           .penalizeLong(HardSoftLongScore.ONE_HARD,
                   Customer::getServiceFinishedDelayInMinutes)
           .asConstraint("serviceFinishedAfterDueTime");
}

Minimize travel time

This is a soft constraint that penalizes the time spent driving per every vehicle, knowing the distances between individual locations.

protected Constraint minimizeTravelTime(ConstraintFactory factory) {
   return factory.forEach(Vehicle.class)
           .penalizeLong(HardSoftLongScore.ONE_SOFT,
                   Vehicle::getTotalDrivingTimeSeconds)
           .asConstraint("minimizeTravelTime");
}

Wait a second, where do we make sure we don’t arrive too early? The serviceFinishedAfterDueTime constraint does it for us, just indirectly. The more time vehicles spend waiting, the fewer customers they can visit without arriving too late.

Try for yourself

1. git clone [email protected]:timefoldai/timefold-quickstarts.git
2. cd timefold-quickstarts/use-cases/vehicle-routing
3. mvn quarkus:dev
4. Open a browser and navigate to http://localhost:8080
5. Click on the solve button

If you want to try your own dataset, use the REST API. Click the Guide in the top-level menu to learn how to get started.

Conclusion

The vehicle routing with time windows is a more practical variation of VRP, which we might translate to domains like field service technician or last mile delivery. You can solve all these using Timefold Solver.

The work on Timefold Solver 1.0.0 is progressing well. We intend to release in early July. This post will give you a sneak peek of what’s coming.

Brand new benchmark report

The solver benchmark report has been completely redesigned and modernized. It now fits nicely on all kinds of screens, from mobile phones to desktops.

Importantly, every chart in the report is now interactive, allowing you to filter the data points to only show those you want to see.

Static pictures don’t do it justice, you need to see it to believe it. Did you know you can build the solver locally to get access to the latest developments before they’re generally available?

Constraint Streams improvements

Constraint Streams are a powerful way to express constraints in a declarative way. In Timefold Solver 1.0.0, they will become even more powerful by introducing the expand()building block. Consider the following constraint:

Constraint speakerRequiredRoomTags(ConstraintFactory factory) {
   return factory.forEach(Talk.class)
       .filter(talk -> talk.missingSpeakerRequiredRoomTagCount() > 0)
       .penalizeConfigurable(talk -> talk.missingSpeakerRequiredRoomTagCount() * talk.getDurationInMinutes())
       .asConstraint(SPEAKER_REQUIRED_ROOM_TAGS);
}

Note that the method missingSpeakerRequiredRoomTagCount() is called twice; once to filter Talk instances and the second time to penalize every one of them. This is not ideal, and it becomes even worse when you realize that under the hood, this method does some heavy lifting to compute the missing tags. The end result is that this constraint is not very efficient. With the new expand() building block, we can rewrite it as follows:

Constraint speakerRequiredRoomTags(ConstraintFactory factory) {
   return factory.forEach(Talk.class)
           .expand(Talk::missingSpeakerRequiredRoomTagCount)
           .filter((talk, missingTagCount) -> missingTagCount > 0)
           .penalizeConfigurable((talk, missingTagCount) -> missingTagCount * talk.getDurationInMinutes())
           .indictWith((talk, missingTagCount) -> Collections.singleton(talk))
           .asConstraint(SPEAKER_REQUIRED_ROOM_TAGS);
}

Notice that the expand() building block caches the computation and propagate it downstream.

We use the not-so-well-known indictWith() building block, which allows us to indicate which facts are responsible for the constraint violation. Since missingTagCountis a plain integer without any semantics, it doesn’t help us to explain the score and therefore it is removed.

Performance improvements and bugfixes

Behind the scenes, we continue to work tirelessly to improve the performance of our solution. With Timefold Solver 1.0.0, users of Constraint Streams will see performance improvements of up to 15% in some cases. And that is on top of the significant speedup that Timefold already brings over OptaPlanner!

Conclusion

Timefold moves ahead at an ever increasing pace. Migrate to Timefold today, and enjoy the benefits of a modern, fast and powerful constraint solver.

OptaPlanner is an Open Source project used globally to optimize operational planning. Every day, it saves thousands of organizations time, money and resources.

On May 2nd, 2023, OptaPlanner entered a new chapter.

The project we worked on for seventeen years has matured under Red Hat’s wings for the past ten years. In 2022, when Red Hat’s strategy changed, it became apparent that the project needed a new, sustainable future. Therefore, we founded a company around it. A company that lives and breathes planning optimization, to further nurture the Open Source project to its fullest potential, under a new name. Timefold is the continuation of OptaPlanner.

Timefold Solver Community Edition is an Apache-licensed Open Source solver for operational planning optimization. It’s a fork of OptaPlanner, and it is already faster, lighter and better documented than OptaPlanner. Timefold has added features and fixed many bugs that still reside in OptaPlanner. Upgrade from OptaPlanner to Timefold today.

The Timefold Solver project is supported by Timefold BV, a professional Open Source company founded by Maarten Vandenbroucke (CEO) and Geoffrey De Smet (the OptaPlanner creator, CTO), with funding from Smartfin, an Open Source minded VC that fully supports our vision. The OptaPlanner team (Lukáš Petrovický, Radovan Synek, and Christopher Chianelli) have joined Timefold. We sell an Enterprise subscription with professional support and high-scalability features, to pay for the continued development of the free Open Source project.

Our mission is to free the world from wasteful scheduling. Our vision is to make Planning Optimization easy to use and simple to build. If you want to learn everything there is to know about planning optimization, follow us on YouTube, LinkedIn or Twitter.

Timefold is committed to be the world’s most powerful, versatile, and easy-to-use planning optimization solver. We combine our advanced AI solver algorithms with constraint models written in Java or Kotlin to be our main differentiator from other solvers. We remain Open Source which ensures a no-barrier entry for every team that wants to start using Timefold. We are hiring the brightest and most creative engineers to explore how we can make planning optimization even more accessible!

FAQ

We understand this message may be unsettling at first, especially if you use OptaPlanner extensively. We apologize for the short-term disruption, but we believe it is necessary to continue the project.

To address all potential concerns, we have compiled a list of Frequently Asked Questions. If you have any other concerns, don’t hesitate to contact us.

Why would I switch from OptaPlanner to Timefold?

Because it’s better:

1. Continuity, responsiveness, know-how and stability: The entire Timefold company is focused on building the best possible planning optimization software and helping you succeed with it. Timefold Solver has many bugfixes and security fixes since it forked from OptaPlanner. We also added powerful new features and enhancements.

1. Performance: Timefold is twice as fast as OptaPlanner out-of-the-box.

1. Distribution size: Cloud deployments love lightweight components. Timefold has all the features of OptaPlanner, but a jar-with-dependencies assembly of the sameHello World program is 41% smaller:

1. Timefold Solver has fewer dependencies. This also speeds up your Maven or Gradle build.
2. Documentation: We are constantly improving the documentation and fine-tuning the quickstarts. It’s easier to get started with Timefold than with OptaPlanner.

Why did you fork OptaPlanner if you created it?

Geoffrey De Smet: "OptaPlanner is my life’s work. As the creator and lead of OptaPlanner, I wrote most of the code (85% according to github - take that with a grain of salt). First seven years in my spare time. Then nine years for Red Hat. I am grateful to each contributor and every user. And I loved working at Red Hat for all those years. Together, we’ve built a wonderful community and a rock-solid project with a strong reputation.

But the work is far from finished. OptaPlanner has a lot more potential.

After the IBM acquisition, Red Hat’s company strategy changed. Business Automation was no longer a priority. Early 2022, Red Hat Decision Manager (the support subscription that paid for my team) movd to IBM, without OptaPlanner. By late 2022, I no longer saw a sustainable future for OptaPlanner’s development within Red Hat.

I could not just let OptaPlanner perish. So I resigned. And over the past few months, I’ve worked on a way to continue and grow the open source project. To build a company around it. An open source company dedicated to planning optimization. Luckily, I met the right people. So I could continue the project.

Over the summer of 2023, Lukáš Petrovický, Radovan Synek, and Christopher Chianelli - the core OptaPlanner engineers - joined Timefold. With their expertise we are able to accelerate the future of Planning Optimization.

So why fork OptaPlanner? I don’t own the DNS name (the optaplanner.org URL) and it’s debatable who owns the trademark. Both are required to build a sustainable business. To rescue OptaPlanner, I had no other option than to fork it."

Is Timefold 100% open source? What’s your business model?

A professional Open Source project needs a viable Open Source business model. Without paying customers, a professional Open Source project cannot survive. Great software developers don’t write code and documentation for free. Not full-time. Not as a team. Everyone needs to eat.

Red Hat sold a support subscription on OptaPlanner. Despite OptaPlanner’s world-wide usage, it struggled commercially. It’s hard to sell support on stable software. Big corporations used OptaPlanner to schedule 10k+ employees in mission critical systems, and often didn’t pay for it.

Therefore, Timefold has an Open Core model. We offer 2 editions:

• Timefold Solver Community Edition (free, Open Source, Apache License 2.0): a comprehensive, well-documented solver for any planning optimization use case. It has no built-in restrictions.
• Timefold Solver Enterprise Edition (paid): A thin layer of additional high-scalability features on top of Timefold Solver Community Edition, specifically to solve large datasets in mission-critical systems far more efficiently. It comes with full enterprise support.

We are committed to Open Source. It is a fundamental part of our company mission. Our future is to actively develop the Community Edition alongside the Enterprise Edition. The revenue of Timefold Solver Enterprise Edition pays for Timefold Solver Community Edition.

New solver features go to Community Edition, except for high-scalability features. The same logic applied during the fork of OptaPlanner: All OptaPlanner features are part of Community Edition, except for Multithreaded Solving and Nearby Selection. Those are part of Enterprise Edition. 90% of OptaPlanner users don’t use either of these. They are pure high-scalability features. Check if this change affects you, by searching for use of moveThreadCount or NearbyDistanceMeter in your code.

How do the OptaPlanner and Timefold versions relate?

• Timefold 0.8.x is a replacement for OptaPlanner 8. It supports Java 11, Java 17, Spring Boot 2, Quarkus 2 and Java EE 8. It has reached its End of Life and is no longer supported.
• Timefold 1.x is a replacement for OptaPlanner 9. It supports Java 17+, Spring Boot 3, Quarkus 3 and Jakarta EE 10.

Is Timefold Backward Compatible with OptaPlanner?

Yes, except for the branding changes.

Run timefold-migration to automatically change all your code locally. It’s a quick, single command for Maven or Gradle. Then test those changes and commit them. Alternatively, apply the following changes manually.

Timefold Solver 1.x is backward compatible with OptaPlanner 8.x, except that:

• Minimum Java 17 (LTS). Java 21 (LTS) and the latest Java version are also supported.
• The Maven/Gradle GAVs changed:
  • The groupId changed from org.optaplanner to ai.timefold.solver.
  • The artifactIds changed from optaplanner-* to timefold-solver-*.
  • ArtifactIds containing peristence- changed from optaplanner-persistence-*to timefold-solver-*.
    • For example, optaplanner-persistence-jackson changed to timefold-solver-jackson.
• The import statements changed accordingly:
  • import org.optaplanner…; changed to import ai.timefold.solver…;.
  • import org.optaplanner.persistence…; changed to import ai.timefold.solver…; too.
• The JEE dependencies changed from javax to jakarta to accommodate Spring 3 and Quarkus 3.
  • This is the same difference as between OptaPlanner 8.x and OptaPlanner 9.x.
• The OptaPlannerJacksonModule class is now called TimefoldJacksonModule.
• The deprecated scoreDRL support is removed, because Drools with its transitive dependencies have been removed entirely.
• The unsecure module persistence-xstream is removed, because of old, unresolved CVEs in XStream.
• The deprecated, undocumented ScoreHibernateType has been removed because of Jakarta. Use JPA’s ScoreConverter instead.

All other deprecated code remains, to make upgrading easy.

What else has changed in Timefold?

• Issue tracking: GitHub issues instead of JIRA.
  • You can now easily submit an issue for us to fix.
• Discussion list: GitHub discussions instead of Google Groups.
• Continuous Integration: GitHub Actions instead of a private Jenkins instance.
  • Our CI jobs are now open to the community.
  • Releases are now automated with JReleaser.
• Security and bugs: Hotfix releases for Timefold Community are now released to Maven Central, immediately.
• Version numbering: The .Final suffix is removed. It had no use.
• Customer response time: Our team replies swiftly on support, sales or other inquiries.

What stays the same?

• High quality
• Regular releases
• Backwards Compatibility guarantees on the API, following Semantic Versioning.
• Our engineers answer questions on Stack Overflow.
• Open culture. Talk to us on GitHub discussions!

Why did you name it Timefold?

Because we fold time and space to plan your operations.

How do I upgrade from OptaPlanner to Timefold?

Upgrade from OptaPlanner to Timefold Solver Community Edition today. It only takes 2 minutes.

Run the command below to upgrade your code automatically. Do a test run of the solver and commit the changes. If it doesn’t work, just revert it instead and submit an issue. We’ll fix it with the highest priority.

MavenGradle

mvn org.openrewrite.maven:rewrite-maven-plugin:6.2.3:run -Drewrite.recipeArtifactCoordinates=ai.timefold.solver:timefold-solver-migration:1.20.0 -Drewrite.activeRecipes=ai.timefold.solver.migration.ToLatest

Timefold Solver 1.x does not support scoreDRL, nor is it upgraded automatically. If you’re still using scoreDRL from OptaPlanner 7.x, please upgrade to Constraint Streams first.

Upgrade from OptaPlanner to Timefold Solver Community Edition today. It only takes 2 minutes.

Run the command below to upgrade your code automatically. Do a test run of the solver and commit the changes. If it doesn’t work, just revert it instead and submit an issue. We’ll fix it with the highest priority.

MavenGradle

mvn org.openrewrite.maven:rewrite-maven-plugin:6.15.0:run -Drewrite.recipeArtifactCoordinates=ai.timefold.solver:timefold-solver-migration:1.25.0 -Drewrite.activeRecipes=ai.timefold.solver.migration.ToLatest

Note: this command is not actively updated. Check our documentation for the command with the latest version numbers.

Timefold Solver 1.x does not support scoreDRL, nor is it upgraded automatically. If you’re still using scoreDRL from OptaPlanner 7.x, please upgrade to Constraint Streams first.

Why would I switch from OptaPlanner to Timefold?

Because it’s better:

1. Continuity, responsiveness, know-how and stability: The entire Timefold company is focused on building the best possible planning optimization software and helping you succeed with it. Timefold Solver has many bugfixes and security fixes since it forked from OptaPlanner. We also added powerful new features and enhancements.
   

1. Performance: Timefold is twice as fast as OptaPlanner out-of-the-box.
   

1. Distribution size: Cloud deployments love lightweight components. Timefold has all the features of OptaPlanner, but a jar-with-dependencies assembly of the same Hello World program is 41% smaller:
   

1. Documentation: We are constantly improving the documentation and fine-tuning the quickstarts. It’s easier to get started with Timefold than with OptaPlanner.

How do the OptaPlanner and Timefold versions relate?

• Timefold 0.8.x is a replacement for OptaPlanner 8. It supports Java 11, Java 17, Spring Boot 2, Quarkus 2 and Java EE 8. It has reached its End of Life and is no longer supported.
• Timefold 1.x is a replacement for OptaPlanner 9. It supports Java 17+, Spring Boot 3, Quarkus 3 and Jakarta EE 10.

Is Timefold Backward Compatible with OptaPlanner?

Yes, except for the branding changes.

Run timefold-migration to automatically change all your code locally. It’s a quick, single command for Maven or Gradle. Then test those changes and commit them. Alternatively, apply the following changes manually.

Timefold Solver 1.x is backward compatible with OptaPlanner 8.x, except that:

• Minimum Java 17 (LTS). Java 21 (LTS) and the latest Java version are also supported.
• The Maven/Gradle GAVs changed:
  • The groupId changed from org.optaplanner to ai.timefold.solver.
  • The artifactIds changed from optaplanner-* to timefold-solver-*.
  • ArtifactIds containing persistence- changed from optaplanner-persistence-* to timefold-solver-*.
    • For example, optaplanner-persistence-jackson changed to timefold-solver-jackson.
• The import statements changed accordingly:
  • import org.optaplanner…​; changed to import ai.timefold.solver…​;.
  • import org.optaplanner.persistence…​; changed to import ai.timefold.solver…​; too.
• The JEE dependencies changed from javax to jakarta to accommodate Spring 3 and Quarkus 3.
  • This is the same difference as between OptaPlanner 8.x and OptaPlanner 9.x.
• The OptaPlannerJacksonModule class is now called TimefoldJacksonModule.
• The deprecated scoreDRL support is removed, because Drools with its transitive dependencies have been removed entirely.
• The unsecure module persistence-xstream is removed, because of old, unresolved CVEs in XStream.
• The deprecated, undocumented ScoreHibernateType has been removed because of Jakarta. Use JPA’s ScoreConverter instead.

All other deprecated code remains, to make upgrading easy.

Timefold, a new company co-founded by OptaPlanner creator Geoffrey De Smet and Maarten Vandenbroucke, is excited to announce the fork of the popular open-source project, OptaPlanner. This marks the beginning of a new era in the operational planning optimization space, with Timefold Community offering enhanced performance, reduced distribution size, and improved documentation over its predecessor.

OptaPlanner, used by thousands of organizations worldwide, has matured over seventeen years, including a decade under Red Hat’s guidance. However, when Red Hat changed strategy last year, the project needed a new, sustainable future. Timefold was created to address this need and help the open-source project reach its full potential.

Timefold Community is an Apache-licensed open-source solver that optimizes operational planning. Backed by Timefold BV, a professional open-source company, the project offers a subscription with professional support and high-scalability features to fund the continued development of the free, open-source project. Timefold has received funding from Smartfin, an open-source minded venture capital firm that fully supports the company’s vision.

With a mission to free the world from wasteful scheduling, Timefold is dedicated to making planning optimization easy to understand and use. The platform leverages advanced AI solver algorithms and code programmable constraint models in Java, Python, and Kotlin, setting it apart from other solvers in the market. Timefold remains committed to being open-source, ensuring no barrier to entry for any team wishing to use the software.

As Timefold continues to grow, the company is actively engineers and experts to explore ways to make planning optimization even more accessible. To stay up to date with the latest developments, follow Timefold on Twitter or LinkedIn.

For more information about Timefold, visit timefold.ai or learn more about why we forked OptaPlanner.

Brussels, Belgium - Timefold, a Belgian-based commercial open source software startup focused on planning optimization through AI, announced today that it has raised 2 million euro in funding from Smartfin VC. The investment will enable Timefold to expand the technology, make it even easier to use, and extend its services to clients worldwide.

Timefold’s AI technology has been used to solve real-world planning problems, resulting in significant economic and ecological benefits. In several cases around the world involving up to tens of thousands of vehicles, Timefold has been able to reduce driving time by 25%. The technology has been applied to complex and high-scale cases where many other solvers have failed, setting Timefold apart from its competitors.

"We are delighted to have Smartfin VC as our investor." said Maarten Vandenbroucke, co-founder of Timefold. "Smartfin VC shares our vision of using AI to solve complex planning problems and create a positive impact in the world. They have been a great help in introducing Geoffrey and I as founders and have provided us with valuable insights into open source venture building."

Smartfin VC is an internationally connected fund that invests in early-stage startups with disruptive technologies. The fund focuses on investing in companies that have the potential to drastically impact markets or industries.

"We are excited to partner with Timefold." said Thomas Depuydt, general partner at Smartfin VC. "Timefold has demonstrated impressive results with its technology in the past, solving planning problems where other technologies have failed. We believe that Timefold has the potential to change the way we approach planning optimization and the usage of resources, and we look forward to working closely with them to achieve their goals."

For more information about Timefold and its AI-powered Open Source planning optimization technology, visit their website at https://timefold.ai.

Every new company needs a logo. So does Timefold. When starting a company, one of the most fun tasks is creating the logo. Far more exciting than VAT accounting, I can tell you.

Of course, a good logo is important: It’s hard to change. It must be able to stand the test of time. It should fit on a variety of media. So we hired a professional to help us: Ivo Blomme, a digital and brand designer with years of experience. He took us through the process of creating a good logo. Based on our input, he created these:

The left one is based on the rectangles of a physical calendar. The right one, with a fold in it, is based on a fold in space and time. Which logo would you have picked?

It was a though call, but we ended going for the second one. It’s loosely based on the idea of folding space and time:

Our designer even showed us how it would look on digital devices:

Now, we don’t have any plans to create a mobile app. But it would look good, wouldn’t it?

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 8.27.0.Final. You can switch from Drools to Bavet in a single line of code.

Twice as fast score calculation. Zero API changes.

Faster

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:

Use caseDroolsBavetSpeed upAverage:53,644136,765+132%cheaptime4,34914,543+234%cloudbalancing162,820608,204+274%coachShuttleGathering38,543111,991+191%conferenceScheduling1,0721,264+18%curriculumCourse32,27238,933+21%examination11,82125,712+118%flightCrewScheduling97,020126,563+30%investment68,935401,806+483%machineReassignment13,38428,619+114%meetingscheduling2,2912,158-6%nQueens177,528285,268+61%nurserostering10,65721,090+98%pas50,97147,551-7%projectjobscheduling23,71578,291+230%rockTour33,997152,472+348%taskAssigning10,53120,680+96%tennis106,172236,437+123%travelingtournament49,42877,143+56%tsp169,125430,384+154%vehicleRouting8,24726,187+218%Table 1. Score calculation speed on different use cases

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.

Scaling

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:

belgium-n50-k10belgium-n100-k10belgium-n500-k20belgium-n1000-k20belgium-n2750-k55AverageDrools76,919/s58,365/s36,609/s23,394/s29,770/s45,011/sBavet307,290/s242,400/s147,595/s89,850/s91,115/s175,650/sSpeed up+299.50%+315.32%+303.17%+284.07%+206.06%+290.24%Table 2. Score calculation speed on different dataset sizes of VRP

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 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.

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.

Stability

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.

More lightweight

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:

Core dependenciesSizeReductionCore exclusionsAll (default)17.5 MB0%noneDrools CS only17.1 MB-2%optaplanner-constraint-drl, optaplanner-constraint-streams-bavetBavet CS only7.0 MB-60%optaplanner-constraint-drl, optaplanner-constraint-streams-droolsTable 3. Distribution size of jar-with-dependencies on OptaPlanner’s hello-world

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

   <dependency>
     <groupId>org.optaplanner</groupId>
     <artifactId>optaplanner-core</artifactId>
     <exclusions>
       <exclusion>
         <groupId>org.optaplanner</groupId>
         <artifactId>optaplanner-constraint-drl</artifactId>
       </exclusion>
       <exclusion>
         <groupId>org.optaplanner</groupId>
         <artifactId>optaplanner-constraint-streams-drools</artifactId>
       </exclusion>
     </exclusions>
   </dependency>

This reduces 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:...

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

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 ConstraintStreamImplType to BAVET:

Plain Java

Switch to Bavet in either your *.java file:

SolverFactory<TimeTable> solverFactory = SolverFactory.create(new SolverConfig()
       ...
       .withConstraintStreamImplType(ConstraintStreamImplType.BAVET)
       ...);

or in your solverConfig.xml:

 <scoreDirectorFactory>
   ...
   <constraintStreamImplType>BAVET</constraintStreamImplType>
 </scoreDirectorFactory>

Quarkus

Switch to Bavet in src/main/resources/application.properties:

quarkus.optaplanner.solver.constraintStreamImplType=BAVET

Spring

Switch to Bavet in src/main/resources/application.properties:

optaplanner.solver.constraintStreamImplType=BAVET

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.