Performance

Four tools and four scenarios. Every tool builds the same source: each tool’s src is a symlink to one copy, and only the manifest (kwenza.toml, pom.xml, build.gradle.kts) differs.

kwenza starts a fresh JVM for every command and keeps nothing running between them. Maven does the same. Gradle’s default is the opposite: the first build starts a background daemon, and every later build reuses it, with its classes already loaded and its compiler already optimised by the JIT. That is a real advantage on a repeated build, and it is why Gradle’s warm figures are much lower than its no-daemon ones.

So the charts show Gradle twice:

Neither is the "right" one. They answer different questions, and a fair reading uses both.

kwenza may gain an optional daemon later, for the same reason: a warm process is the only way to remove JVM start-up and class loading from every build, and that cost matters most on small projects and in a tight edit-and-rebuild loop. It isn’t built, so none of the figures here include one. If it arrives, it will be opt-in and these pages will show it as its own line. See Design Principles for why kwenza doesn’t have one today.

A warm build is one where the dependency caches are already populated, so no run touches the network. The harness does one untimed run first, then times the stated number of clean rebuilds and reports the median and the fastest. kwenza builds from its kwenza.lock; Maven and Gradle use their local caches. Gradle’s daemon, when it is used, is started by the untimed run and stopped after the last timed one. This is what a build costs once a project is set up, and the figure to look at for day-to-day work.

A cold build is the first build on a machine with nothing cached, such as a new CI runner. The tool’s dependency cache is deleted first (and kwenza.lock for kwenza), so the run has to download everything it needs from Maven Central, and each tool does one timed run. Each tool’s cache is separate, so one tool’s downloads never help another.

What a tool needs differs, and that is most of what this section measures. kwenza downloads only what the project declares, because compiling and packaging happen in its own process with no plugins. Maven also downloads the plugins that do each step (compiler, jar, resources, Surefire) and their dependencies. Gradle rebuilds its own caches: the build tool’s libraries and the compiled build script. The Maven and Gradle wrapper distributions (the build tools themselves, about 120 MB) are left in place, since downloading them isn’t part of building your project.

Run from each tool’s project directory, with the environment variables shown. <cache> is that scenario’s isolated cache directory. kwenza is the launcher script, bin/kwenza in a checkout (installed, it’s the same script on PATH); like ./mvnw and ./gradlew, it starts the JVM for you.

You need a JDK, and the first run downloads the Maven and Gradle wrappers. From a checkout of kwenza:

The harness, the three project definitions for each scenario and a README on how it works are in benchmarks/. If you get different results on your machine, or think a tool is being run unfairly, please open an issue.