ForgeZero 4.2.0 has been released — a low-level build orchestrator written in Go, focused on deterministic execution with zero GC pressure.
Key highlights of this release: complete removal of CGO from critical paths, a native Windows loader implemented through syscall, a rewritten assembler hot path using SIMD and sync.Pool, and an on-disk symbol cache in the linker that eliminates `nm` calls.
On a project with 1000 C modules, `fz` achieves 637.3 ms versus Ninja’s 1.813 s.
The gap is **2.84x**.
10 runs. Reproducible.
---
## Benchmark: fz vs Ninja, 1000 C Modules
| Tool | Average | Range | Runs |
| -------------- | -------- | ---------------- | ---- |
| fz (ForgeZero) | 637.3 ms | 626.6 — 685.5 ms | 10 |
| ninja | 1.813 s | 1.800 — 1.834 s | 10 |
Hardware: Intel i5-10310U. Cold filesystem cache. No artificial constraints.
Peak variance for `fz` is 58.9 ms. Ninja shows 34 ms, but from a baseline nearly three times higher. ForgeZero is not only faster — it is more stable in absolute terms.
In the previous release (4.1.0), ForgeZero demonstrated a 3.25x advantage over `make -j4` on 100 modules. On 1000 modules against a specialized parallel build tool, the gap is 2.84x. This is not a synthetic artifact — it is architecture.
---
## CGO Removal
In 4.1.0, CGO was still present in the entry point and in the C plugin loader. Any build touching `cplugin` would pull in a C toolchain, break cross-compilation, and introduce non-determinism into the binary ABI.
In 4.2.0, CGO has been removed completely.
The mechanism is `GoContext`: a pure Go structure replacing the old C-coupled parameter-passing interface used by cplugin. Platform-specific loaders are separated through build tags:
```go
//go:build linux
```
Unix dynamic loader through CGO (for users explicitly enabling it)
```go
//go:build windows
```
Native DLL loader using `syscall` and `golang.org/x/sys/windows`, without CGO.
Fallback builds use a no-op loader compatible with any target.
The `cmd/fz` entry point no longer imports `"C"`. The binary is now fully cross-compilable from any host to any target without a C toolchain.
C module structures are aligned to 64-byte cache line boundaries to eliminate false sharing during multicore scheduling.
---
## Assembler: SIMD, sync.Pool, Zero Allocation Budget
The assembler hot path in 4.1.0 was already fast. In 4.2.0, it operates under a strict zero-allocation budget for every repeated invocation.
### SIMD and branchless lookup tables
Whitespace and comment stripping previously relied on range loops with conditional branches. The implementation has been rewritten into branchless lookup tables with SIMD-width processing — without branch predictor misses in the common case.
### Parser reuse via sync.Pool
Previously, every parsing invocation allocated a new parser struct. The pool stores warmed-up instances and reuses them across goroutines. Allocation noise under sustained parallel load is now effectively flat.
### `splitArgs` rewritten as pooled parser method
The argument splitter used to allocate a new slice on every call. It is now implemented as a parser method reusing the backing array. Slices are reset instead of reallocated.
### `sync.Once` compiler flag parsing
Compiler flags are parsed exactly once. Repeated invocations cost only a single atomic read.
### FastCopy rewrite
FastCopy — the internal instruction stream copy loop — was rewritten into a branchless unrolled function using `unsafe.Pointer` arithmetic.
* No bounds checks
* No interface dispatch
* Direct memory throughput
---
## Linker: On-Disk Symbol Cache, No `nm` Calls
Previously, the linker invoked the `nm` utility to resolve symbol tables. On 1000 modules, this resulted in 1000 process forks with exec overhead, pipe setup, and string parsing.
In 4.2.0, a co-located on-disk symbol cache has been introduced.
Symbol data is written next to object files during the first build and read directly afterward. `nm` is completely removed from the hot path.
Object deduplication was simplified from a custom mmap structure to a native Go map. mmap procedures were removed entirely.
For this workload:
* Go maps are faster
* platform-specific edge cases disappear
* memory behavior becomes deterministic
Response file generation now uses `bufio.Writer`, and `f.Sync` has been removed. Ordering guarantees already exist in the task graph.
---
## Builder and Utils: WalkDir, Zero Copies, Raw Syscalls
Source discovery was rewritten around `WalkDir` with explicit `filepath.SkipDir` support in the custom `SYS_GETDENTS64` traversal layer.
Directory trees that cannot contain build targets are pruned at the kernel level instead of in userspace.
### Additional optimizations
* `CleanDir` deduplicated
* task dispatch loop moved to preallocated task structures
* heap writes removed from the hot path
* unused pools removed
* digest formatting rewritten using stack byte slices instead of `fmt.Sprintf`
### Platform-specific hashing
#### Linux
Direct `SYS_OPENAT` loops with defer cleanup and no `os.File` allocation.
#### macOS
Low-level mmap write interfaces tuned for Darwin unified buffer cache behavior.
#### Windows / non-UNIX
Updated fallback stubs correctly compiling and executing on target platforms.
---
## What 4.1.0 Established
For context, 4.1.0 introduced:
* HADES ELF emitter with correct `.symtab` ordering
* deterministic relocation calculation for `call` and `jmp`
* AEGIS security layer
* TOCTOU mitigation
* atomic SBOM generation
* symlink validation through `secureVendorPath`
The allocation regression suite and enforced `golangci-lint` checks introduced in 4.1.0 remain fully green.
4.2.0 builds on that foundation without breaking it.
---
## Final Numbers
* **2.84x faster** than Ninja on 1000 C modules
* **3.25x faster** than `make -j4` on 100 modules (4.1.0)
* **~1.18 GB/s** copy throughput on i5-10310U
* **0 allocs/op**
* **0 B/op** in `copyFileHot`
* **0 CGO dependencies** in the standard build path
* **100% `golangci-lint` compliance** under strict configuration
---
## Build
```bash
git clone https://github.com/forgezero-cli/forgezero
cd forgezero
go build -o fz ./cmd/fz
```
No C toolchain required.
No network calls during build.
Reproducible output on amd64 and arm64 across Linux, Windows, and macOS.
Sources, benchmarks, and full commit history are available in the repository.
P.S. For CI/CD engineers managing hundreds of projects: there is not a single line of colored terminal output in the codebase, logs are reduced to absolute zero to avoid heap allocations, and the entire filesystem traversal hot path is optimized down to raw kernel syscalls.
The code is fully open source.
Documentation: https://github.com/forgezero-cli/forgezero