Coder Legion - Recent posts tagged perfomance

Ninja is Slow. We Built a Build System in Go That Outperforms It by 39x on a Quarter-Million Tasks

Fri, 03 Jul 2026 13:10:46 +0000

ForgeZero 2.0: We Built a Build System 39x Faster Than Ninja

And yes, it's open source. No bullshit, just architecture.

The Problem Everyone Ignores

You've been there. Sitting at your desk, coffee getting cold, waiting for your build to finish. 10 seconds. 30 seconds. A minute.

CMake parses its DSL. Ninja forks 2,000 processes. Make thrashes the disk. GNU Autotools exists, and everyone pretends not to notice.

This isn't a feature gap. This is architectural malpractice.

Every major build system was designed in an era when parallelism meant "spawn processes." That's it. No thought given to the actual cost—fork syscalls, context switching, memory duplication, I/O bottlenecks.

We decided to fix it properly.

What ForgeZero Actually Is

ForgeZero is a cross-platform build system for C, C++, Objective-C, and Assembly. Written in Go. Single binary. No configuration files needed.

Point it at a directory:

fz build -o binary

It detects your source files, selects compilers (GCC, Clang, Zig), picks assemblers (NASM, GAS, FASM, or embedded), and outputs production-ready binaries, libraries, or ISO images.

That's literally it.

No Makefile. No CMakeLists.txt. No autotools scripts. One command. Full parallelism. Reproducible builds by default.

Repository: https://github.com/forgezero-cli/forgezero
License: GPLv3 (fully open source)

The Benchmark That Broke Ninja's Narrative

Real project. 2,000 object files. 1,000 .c source files. Real hardware.

ForgeZero:  258 ms  (User: 348ms, System: 520ms)
Ninja:      10.1 s  (User: 73.9s, System: 47.8s)

Speedup: 39.2x ✓

This isn't synthetic. This isn't a contrived test case. This is what happens when you link 2,000 real object files on a real codebase.

The gap grows with scale:

File Count	ForgeZero	Ninja	Speedup
1,000	~85ms	~2.7s	32x
2,000	~258ms	~10.1s	39x
10,000	~1.2s	~50s	~42x

Ninja's overhead scales linearly with file count. ForgeZero's scales logarithmically. The larger your codebase, the more you win.

Watch the actual benchmark: https://t.me/wienton/176

Why This Demolishes Every Competitor

1. Architecture: One Process, Infinite Goroutines

Traditional systems:

foreach file:
  fork() → new process
  compile
  wait for completion
  write .o to disk
  read .o back for linking

ForgeZero:

spawn N goroutines (microseconds, not milliseconds)
all 2000 files compile in parallel
all objects stay in memory
linker reads from memory arena
zero context switching overhead

The difference: Goroutine creation = microseconds. Process fork = milliseconds. At 2,000 files, you're talking about 1-2 seconds saved just on process overhead.

2. Zero Allocations in Hot Paths

This is the part other build systems don't even think about.

BenchmarkLinkerHotPath:  0 allocs/op, 0 B/op
BenchmarkCodegenHotPath: 0 allocs/op, 0 B/op
BenchmarkHashBLAKE3:     0 allocs/op, 0 B/op

No garbage collection pauses. No "stop-the-world" events. Deterministic latency like C or Rust.

Achieved through:

Pre-allocated arenas for intermediate objects
Stack buffers for I/O operations
sync.Pool for temporary structures
Zero make(), append(), or new() in critical sections

When you're linking thousands of files, GC pauses compound. We eliminated them entirely.

3. Memory-Resident Object Cache

Ninja writes every .o file to disk, then reads it back. Disk I/O at SSD speeds is 500 MB/sec.

ForgeZero keeps objects in memory: 10+ GB/sec throughput.

On a 2000-file project, this alone saves 200-300ms.

4. BLAKE3 Instead of SHA-256

Caching depends on file hashes. SHA-256 is cryptographically solid but slow.

BLAKE3 is:

7x faster than SHA-256
Parallel (SIMD accelerated)
Cryptographically modern

On 2000 files: SHA-256 (~500ms) vs BLAKE3 (~70ms). That's 430ms saved per rebuild.

5. Custom Lock-Free Scheduler

ForgeZero doesn't rely on the OS scheduler. It implements its own:

Mutex, Semaphore, WaitGroup (no external dependencies)
Lock-free ring buffer for task queues (CAS atomics)
Worker pool with goroutine reuse
Atomic counters (no mutex contention)

Even under load, zero contention. Maximum throughput.

What's New in ForgeZero 2.0 (v5.3.0)

Embedded x86 Assembler

NASM is gone. ForgeZero now includes a native Intel-syntax assembler that generates correct ELF64 object files.

One dependency eliminated
Works on all platforms (Linux, Windows, macOS)
Same behavior everywhere

ISO Image Generation

fz build -iso -iso-out kernel.iso
qemu-system-x86_64 -cdrom kernel.iso

For kernel and firmware developers: no more mkisofs scripts. One flag. Bootable ISO. Done.

Support for -iso-hybrid (BIOS + UEFI).

Three Cache Modes

fz build                  # disk mode (default, persistent)
fz build -cache=ram       # memory mode (CI/CD, ephemeral envs)
fz build -cache=off       # no cache

Perfect for Docker containers where disk is slow or ephemeral.

Inline Bash Scripts

scripts:
  - bash: echo "Building..."
  - bash: ./configure --prefix=/usr
  - bash: make install

If no shell exists, uses embedded minimal runner (cd, export, direct binary calls).

Rollback Support

fz --rollback              # Revert to previous version
fz --rollback-to v5.2.0    # Revert to specific version

Production-grade versioning. If something breaks, you recover in seconds.

Rewritten Scheduler

Removed external workerpool dependency. Built custom with:

Better error aggregation
Context-based cancellation
Graceful shutdown
Full race condition safety

Rewritten Config System

Low-allocation merging (no unnecessary copies)
Parallel config loading
Clear merge semantics (strings override, slices deduplicate, maps merge)
Safe defaults with validation

Cross-Platform Reality

Single codebase. Three platforms. Identical behavior.

Linux:

Direct syscalls via golang.org/x/sys/unix
SYS_OPENAT, SYS_UNLINKAT
No libc

Windows:

Native implementation via golang.org/x/sys/windows
CreateFile, ReadFile, WriteFile APIs
Retry logic for file locks

macOS:

Full Darwin syscall support
Identical behavior to Linux

VFS Layer abstracts all OS differences:

Path/separator normalization
TOCTOU attack prevention
Symlink boundary enforcement (security by default)

Built-In Security (Not Bolted On)

fz audit — SAST Scanner

fz audit              # Scan for all issues
fz audit --strict     # Strict mode

Detects:

Secrets (AWS keys, GitHub tokens, API keys)
Dangerous patterns (gets, sprintf without bounds, alloca in loops)
License violations (GPL/AGPL in proprietary projects)
Known CVEs in dependencies

fz sbom — Software Bill of Materials

fz sbom --output sbom.xml

CycloneDX format with BLAKE3 hashes for every component. Essential for aerospace, medical, and fintech systems.

fz verify — Source Integrity

fz verify --manifest .fz.manifest

Checks every file against BLAKE3 manifest. Detects corruption and supply chain attacks.

--reproducible — Bit-for-Bit Reproducibility

fz build --reproducible

Two builds of identical code produce identical binaries (down to the last byte):

Build ID suppressed
Timestamps zeroed
Paths normalized
Order deterministic

Verifiable that no one modified your source.

fz doctor — Environment Diagnostics

fz doctor

Checks:

Compiler availability and versions
File access permissions
Platform integrity
Required dependencies

Human-readable report of what works and what doesn't.

Supported Everything

Category	Details
Languages	C, C++, Objective-C, Assembly (NASM/GAS/FASM), Gloria (custom bare-metal language)
Output	ELF, PE, Mach-O, static libraries, shared libraries, flat binaries, ISO images
Cross-Compilation	ARM (32/64), RISC-V, WebAssembly, Windows, full support via Zig toolchain
Tools	`-compile-commands` (LSP), `-watch` (file monitoring), `-shell` (REPL), `-bench` (profiling), `-debug` (DWARF symbols)
Advanced	Bare-metal linking, custom linker scripts, freestanding environments, BIOS+UEFI support

Package Manager (fz pm)

fz pm add <repo>[@version]    # Add from Git
fz pm remove <package>         # Remove
fz pm list                     # List installed
fz pm catalog                  # Browse official catalog
fz pm search <query>           # Search
fz pm install <name>           # Install with BLAKE3 verification

All packages verified with BLAKE3 before installation. No npm dependency hell.

The Numbers Don't Lie

976 commits in 2 months (16 commits/day—this is sprint-grade work)
42,048 lines of code (32,275 Go, rest tests + docs)
234 Go files
90%+ test coverage on critical packages
0 allocations in hot paths (benchmarked)
100% golangci-lint in strict mode
Passes all -race checks (no data races)
Works on Linux, Windows, macOS with zero code changes

This is not fantasy. This is production-grade code.

Comparison: The Reality Check

Feature	Make	Ninja	CMake	ForgeZero
Config files	Yes	Yes	Yes	No
Caching	No	Limited	No	3 modes
Parallelism	Processes	Processes	Processes	Goroutines
Zero-alloc paths	No	No	No	Yes
Embedded assembler	No	No	No	Yes
ISO images	No	No	No	Yes
Package manager	No	No	No	Yes
SAST/SBOM	No	No	No	Yes
Cross-compilation	Limited	Limited	Limited	Full
Speed	Baseline	Fast	Medium	39x Ninja
Windows native	Limited	Limited	Yes	Yes
Rollback support	No	No	No	Yes
Reproducible builds	No	No	No	Yes

One system dominates every dimension.

System Requirements

OS: Linux, Windows (native or WSL2), macOS
Architecture: amd64, arm64
Optional: GCC/Clang (C/C++), Zig (cross-toolchain), Git (package manager)
For ISO: xorriso (separate installation)

Everything else is embedded in a single binary.

Why This Matters: The Reality

Speed Changes Workflow

Before: 10 seconds per rebuild = context lost
After:  250 milliseconds per rebuild = never interrupt flow

This isn't productivity theater. This is fundamental work process improvement.

On a 50-engineer team, if each engineer rebuilds 50 times per day:

Ninja:      10s × 50 builds × 50 engineers = 41,666 seconds wasted
ForgeZero:  0.25s × 50 builds × 50 engineers = 1,041 seconds wasted

Saved: 40,625 seconds/day = 11.3 person-hours/day

That's literally one full-time engineer's output, reclaimed.

No Config = No Errors

CMakeLists.txt, Makefile, autotools—these are programming languages with their own syntax, semantics, and pitfalls.

ForgeZero needs zero configuration to work. YAML if you want customization. That's it.

New developers don't spend a day figuring out the build system. They fz build. Done.

Systems Work Is Irreplaceable

This tool exists because systems programming is fundamentally different. You can't CMake your way out of bare-metal development.

Kernel developers need embedded assembly → we built it in
Firmware developers need ISO images → integrated
Security-critical projects need SBOM and reproducible builds → bundled
Embedded devs need cross-compilation → fully supported

We're not trying to replace Gradle or Maven. We're building the right tool for systems work.

The Roadmap

We're not done:

Linux Kbuild support for kernel compilation
Enhanced IDE integration (VSCode, CLion)
Gloria language expansion (custom systems language)
Further performance optimization (targeting 50x+ speedup)
Additional architecture support (PowerPC, MIPS)

This is a living project. 976 commits in 2 months. Not a one-off. Not a side project. Real engineering work.

Who This Is For

You're a Systems Programmer

Building kernels, bootloaders, or firmware
Need deterministic, reproducible builds
Want security integrated, not bolted on
Tired of Makefile spaghetti

This is for you.

You Manage a Build Infrastructure

Your CI/CD pipeline is 60% waiting for builds
You want to scale without renting more cloud resources
You need reproducible, verifiable builds

This saves money and time.

You Care About Simplicity

You believe configuration is a source of bugs
You want tools that work zero-config and scale up
You respect your developers' time

This respects your choices.

Get Started

# Linux/macOS
curl -sSL https://raw.githubusercontent.com/forgezero-cli/ForgeZero/main/install.sh | bash

# First build
fz build -o my_program

# Watch the speed difference
touch src/main.c && fz build -o my_program

Follow updates: https://t.me/wienton/176

The Statement

ForgeZero isn't an improvement on Ninja. It's not an optimization of Make. It's a complete rewrite of what a build system should be, informed by:

Modern hardware (multi-core, SIMD, large memory)
Modern languages (Go, with its goroutines and concurrency primitives)
Real systems work (assembly, bare-metal, cross-compilation)
Security best practices (reproducible builds, SBOM, SAST)

This is a challenge to the industry: Slow builds aren't inevitable. They're architectural choices. Fix the architecture, and speed fixes itself.

If you're tired of waiting for builds. If you're exhausted by CMake configuration. If you just want to code, not configure—ForgeZero is for you.

The Details

Author: Alex Voste

Repository: https://github.com/forgezero-cli/forgezero

Latest Release: v5.3.0

License: GPLv3 (fully open source, fully free)

Fast builds aren't a luxury. They're an engineering necessity. ForgeZero delivers.

Make it so.

Why I Built My Own Build Orchestrator, Compiler Toolchain, and Package Manager for Low-Level Devs

Tue, 09 Jun 2026 11:18:26 +0000

Hi everyone. If you’re into systems engineering, writing raw C, or wrangling assembly (NASM/FASM/GAS), you know exactly what building a massive project turns into. You either drown in sheets of legacy Makefile spaghetti, or you deploy a monstrous CMake configuration that generates Ninja files under the hood, which then... well, the overhead just keeps piling up.

My name is Alex Voste. I’m a network systems engineer, and honestly, I got sick of watching modern build tools turn into bloated behemoths wrapped in dozens of external dependencies.

So, I built ForgeZero — a multi-platform, high-performance build orchestrator and toolchain with absolute zero overhead (zero-overhead). In this post, I’ll break down exactly why I chose to go through this nerve-wracking process, the architectural brick walls I slammed into, and why it's time to retire the industry’s "sacred cows."

The Core Problem: The Over-Engineered Build Stack

Let’s be real: modern build systems were designed either for a completely different era or for massive OOP projects. When you need to build low-level infrastructure where C and hand-optimized assembly must intertwine seamlessly, you hit three walls:

Monstrous Syntax: CMake configurations often end up more complex than the actual source code of the project.
Hidden Allocations and Parsing Overhead: Build systems waste critical seconds just parsing dependency trees, checking environment variables, and writing intermediate files for another build runner.
Supply Chain Blindspots: Traditional package managers pull dependencies from everywhere, while linkers silently swallow insecure flags.

The ForgeZero Philosophy

I architected ForgeZero (written in Go) around the principle of minimizing abstractions. A single .fz.yaml file isn't just a replacement for a Makefile; it’s a strict, declarative blueprint of what needs to be built, stripping away logical loops and hidden workarounds.

Out of the box, the tool wraps NASM, GAS, FASM, GCC, Clang, LD, and Zig into a unified interface, executing parallel builds with native zero-allocation mechanics in critical execution paths.

Validating Performance Against the "Standards"

Philosophy means nothing without speed. For me, predictability and raw performance are non-negotiable.

I’ve spent a lot of time running benchmarks on massive synthetic environments (generating and building test projects containing anywhere from 1,000 to 4,000 separate modules) as well as compiling canonical codebases like SQLite.

If you want to see the detailed breakdowns, raw logs, and the exact graphs showing how this custom tool outpaced standard CMake + Ninja setups, feel free to dig through my previous benchmark posts here on my profile.

The short version? Eliminating intermediate file-writing steps, dropping repetitive AST parsing, and managing concurrency via a custom Go scheduler cuts down compilation orchestration time significantly.

Ecosystem Integration and `pkgman`

A build orchestrator is useless if you still have to manually fetch tarballs and hardcode include paths just to link a library. To fix this, ForgeZero includes a lightweight package manager.

Zero Runtime Overhead: Dependencies are resolved atomically, cached locally, and strictly linked to your binary.
Hermetic Security: Every package carries a strict cryptographic signature. This is a step toward Sovereign Engineering — ensuring your build pipelines are completely isolated from upstream supply-chain attacks during critical compilations.

The Pros, the Cons, and the Mental Toll

Writing a custom toolchain from scratch as a solo engineer is a great way to burn out. Here is a candid technical retrospective of what worked and what didn't.

🔴 The Cons (The Pain Points):

Cross-Platform Linker Hell: Getting compilers and linkers (especially on Windows and macOS with their proprietary SDK paths and specific macros) to behave predictably through a single wrapper is absolute torture. The subtle behavioral differences between GNU ld, LLD, and the classic macOS linker cost me weeks of troubleshooting.
Fighting for Microseconds in Go: To beat highly optimized native tools like Ninja, I had to completely rewrite our config parser and abandon standard file path utilities (path/filepath), because they caused too many heap allocations when scanning thousands of source modules.
Community Skepticism: You constantly get hit with "Why not just use CMake?" — right up until someone tries to build a complex, multi-dialect C/ASM project with a single command without configuring a complex local environment first.

🟢 The Pros (The Payoff):

Absolute Determinism: I know exactly how the binary is linked, which security and optimization flags are passed down, and I can guarantee no malicious injection happened during the build phase.
Snappy Developer Experience: The speed difference is physical. When your "save-and-test" iteration loop happens instantly, it completely shifts your development flow.
Unified Control: No more splitting builds where assembly is thrown into NASM, the C backend is built via GCC, and everything is glued together by brittle Bash scripts. Everything lives inside a tight, predictable lifecyle.

Beyond Building: Introducing Gloria JIT

ForgeZero isn't just a wrapper for existing tools; it’s evolving into a complete, sovereign development ecosystem. I’m currently building Gloria — a custom low-level programming language designed to compile directly into lightweight, raw native binaries with zero runtime dependencies.

No heavy runtimes, no bloated headers. Here is a quick look at compilation in action, spitting out an 85-byte execution payload:

Final Thoughts

ForgeZero isn't trying to "kill" CMake for the enterprise world. It’s an engineered tool for developers who are tired of needless complexity, who care about every millisecond of their build pipeline, and who demand transparency from their compilation process.

The toolchain is battle-tested against heavy production scenarios, and the performance gains prove that moving away from legacy software layers is a viable path forward.

How are you handling configuration fatigue and dependency hell in your C/Assembly stacks? Let's talk in the comments.

Documentation - https://github.com/forgezero-cli/forgezero

Want to contribute?

The ecosystem is growing rapidly, and I’m looking for like-minded systems engineers, compiler devs, and low-level enthusiasts who want to help break away from bloated legacy standards. If you want to contribute to the orchestrator, the toolchain, or help shape the Gloria compiler, jump in! Check out the repository, review the architecture, and let’s build this together.