A free Go-based Kotlin compiler, kc, builds JVM libraries 10x to 16x faster than JetBrains' kotlinc at one-tenth the RAM

Bartek Teodorczyk's kc compiles real Kotlin libraries like kotlinx.coroutines and Ktor in a fraction of a second, against seconds for a warm kotlinc. It's a prototype that skips most of kotlinc's checks, and its README lists exactly what it leaves out.

By Chris Pirillo · November 1, 2026 · 5 min read

Illustration: LockerGnome

Why it matters

The numbers are on real code. The benchmark ran on an M2 MacBook Air against kotlinc 2.4.21, kept warm “as it does in the Gradle daemon.” kotlinpoet took 1.23 seconds in kotlinc and 97 milliseconds in kc. Three Ktor modules went from 2.32 seconds to 226 milliseconds. kotlinx-coroutines-core went from 2.50 seconds to 159.

The checks it skips don’t explain the gap. kotlinc runs 290 checkers for warnings and errors that kc doesn’t have. So the author profiled both on one thread with 500 generated files, and kc was faster at every phase both compilers run. Parsing came out about 18 times faster, and code generation about 14. “Even without its checkers, kotlinc would take 33 s, 13x as long as kc.”

The libraries it builds still pass their tests. The README says the libraries kc builds “pass their own test suites,” and that kc passes 95% of kotlinc’s own box tests.

The README gives four reasons for the speed. kc has no JVM to start, so it “starts in milliseconds,” where a cold kotlinc spends seconds warming up. It parses, checks and writes class files on every core, while kotlinc’s front end uses one. It writes code in a single pass, where kotlinc’s time is “spread over 88 IR lowerings and 290 checkers, none above about 2%.” And it indexes the class path in about 5 milliseconds, decoding a class only when something uses it.

Cold starts are where the gap gets wide. With a fresh JVM per build, the way a command line or a CI runner does it, kotlinc took 6.9, 19.2 and 10.9 seconds on the three libraries, 69 to 85 times slower than kc. Peak memory for kc was 85 to 118 MB, and cold kotlinc with an 8 GB heap limit reached 1.0 to 1.1 GB.

The README is as plain about what kc doesn’t do. It leaves out some of the language, and it doesn’t check visibility. It agrees with kotlinc on only 79% of the diagnostics tests, because it reports only the errors type checking finds. There’s no Kotlin/Native, JavaScript or Wasm, no incremental compilation, no Gradle plugin and no IDE support. Its class files “work the same, but differ in places”: for kotlinx-coroutines-core it writes 790 classes where kotlinc writes 850, because it shares the objects of inline functions instead of copying them.

Steal this

Try kc where a slow compile hurts most, a CI job or a quick command-line build, and keep kotlinc as the build of record. kc’s widest margin is cold starts, and it still skips most of kotlinc’s checks. This is like a spell-checker that runs as you type: catch the obvious mistakes fast, then give the final draft to the editor.
Before you trust a speed claim, ask what the fast tool leaves out, then look for the profile. kc’s author answered the obvious objection by timing every phase both compilers share. Kind of like comparing two cars’ lap times only after checking that both ran the same track.
Test it on your own project with the README’s Gradle init script, which swaps a module’s Kotlin compile task for a call to kc. You’ll need Go 1.27.2 or newer, a JDK, and the standard library jar on the class path, since kc doesn’t add it. This is like a test drive with your own groceries in the trunk: the dealer’s route says less than your commute.

The list of unsupported Kotlin is the document to watch. The repo went up on October 31, and the benchmark notes give the scripts to repeat every number, so the first outside timings on someone else’s machine are one clone away.

Search

A free Go-based Kotlin compiler, kc, builds JVM libraries 10x to 16x faster than JetBrains' kotlinc at one-tenth the RAM

More Software