Grit compiles GDScript to C++, but profile your game first

Grit is a new experimental toolchain that translates Godot’s GDScript into C++ and then compiles that C++ to native code. GameFromScratch covered it on 9 November 2026, and GameDev.net republished the report the same day. The headline number is modest. Reported gains start at about 1.1x, and the write-up says results depend on how your project is built and how much of its work actually runs in script.

What Grit is and what we know so far

GDScript normally runs on Godot’s own virtual machine. That is a small interpreter inside the engine that reads your compiled script and executes it step by step. Grit takes a different route. It converts your scripts to C++ source, then hands that source to a normal C++ compiler to produce machine code.

The idea is appealing because you keep writing GDScript and get native code out the other end. In theory that removes the interpreter overhead on tight loops and maths-heavy functions.

The coverage we could read is thin on detail. The GameDev.net report doesn’t name the developer, give a licence, list supported Godot versions or say which GDScript features work. It also flags extra build complexity as a cost. We couldn’t load the project’s own page from our research setup, so we’re not going to guess at the rest. If you plan to try it, read the repository’s readme and licence file yourself before you add it to a real project.

How it compares with earlier attempts

Grit isn’t the first project to try this, and the history is useful context.

• GDCC describes itself as an ahead-of-time compiler, meaning it compiles before the game runs, that turns GDScript into a GDExtension binary module. Its repository lists an LGPL-3.0 licence, a beta status and Godot 4.5 or later.
• A Rust-output compiler shared on r/godot in May 2024 generated Rust from GDScript. Its author reported a Fibonacci test at 77 ms against 390 ms in GDScript, but calls to other nodes and other files weren’t supported, and work paused.
• GD++, posted on the Godot Forum on 2 October 2026, goes the other way. It’s a GDScript-like language that targets C++. Its author reported a 5 to 10x speedup on one foliage add-on after porting it.
• An in-engine JIT, short for just-in-time compiler, is being explored in a fork by Konstantin Pigulevskiy. His January 2025 research post calls the code a draft, still working on basic number types.

Godot itself hasn’t committed to native compilation for GDScript. In a 2020 progress report, George Marques said the new compiler design could make targets such as LLVM or C easier later, but that those ideas weren’t settled.

The pattern across these projects is consistent. Simple maths gets much faster. Code that leans on the engine, such as calls to other nodes and other scripts, is where these tools have struggled or gained less.

What it means for a solo dev or small team

In many indie projects, frame time goes on physics, rendering, large node counts or an algorithm doing far more work than it needs to. A script compiler can’t fix any of those, and your profiler will tell you which one you have. That is likely why Grit’s reported floor is 1.1x. If your frame time is spent inside engine calls, translating the script around those calls changes little.

Compare that with what you already have for free. Godot’s 2020 report measured typed operations at roughly 25 to 50% faster than untyped ones in debug-build benchmarks. Adding static types to a hot function costs you nothing beyond a few annotations and needs no new toolchain.

There’s also a maintenance cost. A tool that adds a C++ compile step to your export means another thing that can break on a Godot update, on a new platform or on a teammate’s machine. That risk is fine for an experiment. It’s harder to justify for a game with a release date, especially when the project’s licence and long-term support are unclear to us.

When you do need native speed, Godot already has supported paths. GDExtension with godot-cpp lets you write a hot system in C++ and call it from GDScript. C# is the other official option, though you need the .NET build of the engine. Both are documented by the Godot team, and both let you move only the slow part while the rest of your game stays in GDScript.

What to do now

If your game feels slow, work through these in order.

1. Profile first. Open the profiler in the debugger panel and find out where frame time goes. If script functions aren’t near the top, a script compiler won’t help.
2. Fix the algorithm. Look for work done every frame that could run once, nested loops over large arrays, and repeated node lookups. Cache references and use timers instead of polling.
3. Add static types. Type the variables and function signatures in your hottest scripts, then profile again.
4. Move one hot system to native code. If a single function still dominates, rewrite just that piece as a GDExtension class or in C#. Keep the rest in GDScript.
5. Try Grit on a branch, if you’re curious. Copy your project, pick one script-heavy scene and measure before and after on the same machine. Run each build three or four times and compare average frame times, not a single run. Test on your lowest target device too, since a gain on a fast desktop may vanish on a handheld. Check the licence and which features it supports before anything ships.

We’d treat Grit as one to watch rather than one to adopt. If later versions publish clear benchmarks, a feature list and a stable licence, we’ll take another look.

Sources

• Grit: GDScript-to-C++ Compiler, via GameFromScratch (GameDev.net)
• GDScript progress report: Typed instructions (Godot Engine blog)
• GD++: a boilerplate-free language that targets C++ (Godot Forum)
• GDScript codegen research: 01 (bag-dev-blog)
• GDScript compiler is dead, but not really (r/godot)
• GDCC (script-gd on GitHub)
• Static typing in GDScript (Godot docs)
• The Profiler (Godot docs)
• About godot-cpp (Godot docs)