Skip to content

About

libxev built two ways: azazel (CUE model) and zaza (C/C++ graph), with a speed + structure comparison

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Latest commit

 

History

9 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

azazel-parity-libxev

libxev built two ways, to prove and compare azazel and zaza against a real upstream project.

  • azazel builds libxev's C-API static library (libxev.a) from source. The build is declared as data in a CUE model.
  • zaza builds a C consumer of that library through its C/C++ target graph.

Neither vendors libxev's sources. Each side stages the pinned upstream with its own fetch.sh into a git-ignored vendor/.

Pinned upstream

Repository https://github.com/mitchellh/libxev
Commit 9ce8e8e6ff89e583258a7f8e7adeeeaeae8611bf
Zig 0.16.0 (libxev's minimum)

Build it

# azazel: build libxev.a from source via the CUE model
cd azazel && ./fetch.sh && sh gen_build_spec.sh && zig build
# -> zig-out/lib/libxev.a

# zaza: build + run a C consumer of libxev's C API
cd zaza && ./fetch.sh && zig build run
# -> zaza+libxev slice: event loop ran, timer fired 1 time(s)

Comparison

Clean-cache builds with dependencies pre-fetched, Apple Silicon, fastest of two runs. native is the upstream's own zig build.

Build Clean build Config
azazel 4.5 s project.cue — 10 lines · 415 B
zaza 3.9 s build.zig — 51 lines · 2061 B
native (the upstream's own zig build) 4.8 s —

azazel and zaza build libxev's C-API library faster than libxev's own full build; azazel states it in a tenth the config bytes.

Build process & what can be optimized

Both build roots stage the pinned upstream with fetch.sh into a git-ignored vendor/ (a curl for single-file slices, a shallow clone for source trees) — no upstream sources are committed. Then:

  • azazel: sh gen_build_spec.sh runs CUE and emits build_spec.zig (the build declared as data), then zig build compiles it. The CUE step is memoized — it re-runs only when the model changes (~0.20s → ~0.01s otherwise).
  • zaza: zig build drives the standard Zig build graph directly.

What actually makes it faster

Measured across the corpus (clean vs warm builds):

Lever Speedup Note
Content-addressed cache (rebuild) 89× 14.2s → 0.16s; Zig has it, both inherit it
Incremental (edit one file) 10.8× 14.2s → 1.32s; deps stay cached
CI dependency cache 2× cold 13.3s → warm 6.6s; this repo's CI caches ~/.cache/zig
Memoized CUE codegen 20× azazel's only overhead, gone
Parallelism (many cores) 1.1× marginal — shared std + startup dominate
GPU none compilation is branchy, sequential, dependency-ordered

The instinct to parallelize like a C++ build doesn't transfer: Zig is one mostly-single-threaded compile per artifact with a fast self-hosted backend and a shared std that caches. For Zig, caching is the lever, not parallelism.

The real frontier is residency: a resident compile server that keeps the InternPool hot and recompiles only changed declarations, plus in-place binary patching (Zig's roadmap) and a shared content-addressed cache. azazel's build-as-data is positioned for it — the build is a query, and the cache key is computable from the pinned model without running the compiler. Full write-up and the cross-repo comparison: the corpus dashboard.

About

libxev built two ways: azazel (CUE model) and zaza (C/C++ graph), with a speed + structure comparison

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages