---
title: "604ms Rebuilds at 50,000 Modules"
date: 2026-05-28
type: post
tags: [bundler, performance, cloudpack, architecture]
summary: "Traditional bundlers start from scratch every time. Cloudpack maintains the module graph continuously and treats every output as a query. The result: 604ms warm rebuilds at 50,000 modules."
---

604ms. Warm rebuild, 50,000 modules. One file changed, one file re-summarized, the rest served from a content-addressed cache. Graph analysis runs on metadata alone and finishes before you lift your finger off the save key.

This is [Cloudpack](https://github.com/kenotron-ms/cloudpack). The architecture borrows more from linker engineering than from anything in the JavaScript ecosystem. Here's how we got there.

## The ceiling

Every JavaScript bundler shares the same foundational architecture: read all source files, analyze the full module graph, emit output. Vite, webpack, esbuild, Rspack, Rolldown. Each generation made the traversal faster. None of them changed what gets traversed.

At 1,000 modules this works. At 10,000, builds take seconds and developers lose flow. At 50,000, CI runs in minutes, hot-reload delays compound into thousands of lost engineer-hours per month, and the problem gets linearly worse as the product grows.

This is not a vendor problem. It is a category problem. Build time scales with total module count, not with what changed. Rewriting the traversal in Rust makes O(n) faster. It does not make it O(Δ).

## Compiler vs database

The traditional bundler is a compiler. Source files go in, a bundle comes out, the next build starts over.

Cloudpack is a database. The module graph persists across builds. Every output (dev server, CI artifact, production chunks, per-client delta manifest) is a materialized view of that graph. One truth, many queries. No separate dev/prod pipeline. No divergence.

**The module graph is the software. The bundle is a query.**

<div class="breakout">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 840 400" role="img" aria-label="Diagram: Compiler vs Database, two mental models for JavaScript bundling compared side by side">
  <rect width="840" height="400" fill="#F5F0E8" rx="4"/>
  <text x="210" y="32" text-anchor="middle" font-family="Georgia, serif" font-size="16" font-weight="bold" fill="#2B2421">Traditional Bundler</text>
  <text x="210" y="50" text-anchor="middle" font-family="Georgia, serif" font-size="12" fill="#A0522D">Compiler</text>
  <text x="630" y="32" text-anchor="middle" font-family="Georgia, serif" font-size="16" font-weight="bold" fill="#2B2421">Cloudpack</text>
  <text x="630" y="50" text-anchor="middle" font-family="Georgia, serif" font-size="12" fill="#A0522D">Database</text>
  <line x1="420" y1="16" x2="420" y2="380" stroke="#2B2421" stroke-width="1" stroke-dasharray="4,4"/>
  <rect x="60" y="68" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="210" y="93" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">Read all 50,000 source files</text>
  <line x1="210" y1="108" x2="210" y2="126" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a1d)"/>
  <rect x="60" y="128" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="210" y="153" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">Parse + analyze entire graph</text>
  <line x1="210" y1="168" x2="210" y2="186" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a1d)"/>
  <rect x="60" y="188" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="210" y="213" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">Emit bundle</text>
  <line x1="210" y1="228" x2="210" y2="246" stroke="#A0522D" stroke-width="1.5" marker-end="url(#a1r)"/>
  <rect x="80" y="248" width="260" height="40" rx="4" fill="#A0522D" stroke="none"/>
  <text x="210" y="273" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#F5F0E8">Next build: start over from scratch</text>
  <text x="210" y="316" text-anchor="middle" font-family="Georgia, serif" font-size="14" font-weight="bold" fill="#A0522D">Cost: O(n) always</text>
  <text x="210" y="338" text-anchor="middle" font-family="Georgia, serif" font-size="12" fill="#2B2421">50k modules = 50k modules of work</text>
  <rect x="480" y="68" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="630" y="93" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">1 file changed → re-summarize 1</text>
  <line x1="630" y1="108" x2="630" y2="126" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a1d)"/>
  <rect x="480" y="128" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="630" y="153" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">Query graph (summaries only)</text>
  <line x1="630" y1="168" x2="630" y2="186" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a1d)"/>
  <rect x="480" y="188" width="300" height="40" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="630" y="213" text-anchor="middle" font-family="monospace" font-size="12" fill="#2B2421">Transform 1 changed module</text>
  <line x1="630" y1="228" x2="630" y2="246" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a1d)"/>
  <rect x="500" y="248" width="260" height="40" rx="4" fill="#2B2421" stroke="none"/>
  <text x="630" y="273" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#F5F0E8">Graph persists. Done.</text>
  <text x="630" y="316" text-anchor="middle" font-family="Georgia, serif" font-size="14" font-weight="bold" fill="#2B2421">Cost: O(Δ)</text>
  <text x="630" y="338" text-anchor="middle" font-family="Georgia, serif" font-size="12" fill="#2B2421">50k modules, 1 changed = 1 of work</text>
  <line x1="60" y1="358" x2="780" y2="358" stroke="#2B2421" stroke-width="0.5"/>
  <text x="420" y="382" text-anchor="middle" font-family="Georgia, serif" font-size="13" fill="#2B2421">Same codebase. Same change. Different architecture.</text>
  <defs>
    <marker id="a1d" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
      <polygon points="0 0, 8 3, 0 6" fill="#2B2421"/>
    </marker>
    <marker id="a1r" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
      <polygon points="0 0, 8 3, 0 6" fill="#A0522D"/>
    </marker>
  </defs>
</svg>
</div>

Change one file in a 50,000-module application. A compiler re-reads everything. A database updates one row and re-runs the affected queries.

## Three phases

Cloudpack splits the build into three phases, each with a different cost model.

**Phase 1: Summarize.** Parse each source file into a ~2KB `ModuleSummary`: exports, imports, side-effect markers, inter-export call edges, ambient global references. Runs in parallel via `rayon`, one task per file, no shared mutable state. Cached by `SHA-256(source)`. A file that hasn't changed costs zero. At 50,000 modules the entire summary set is ~100MB. That fits in L3 cache.

**Phase 2: Analyze.** Read all summaries, build the full module graph. Three passes: BFS/DFS reachability from entry points, call-edge dead code elimination, delivery group assignment. Operates on summaries only, never source. At 50,000 modules this is a bandwidth-bound serial scan finishing in ~50ms. It re-runs only when a summary's import or export structure changes. Implementation-only edits (function bodies, comments, formatting) skip it entirely.

**Phase 3: Transform.** Produce output files for alive, changed modules only. Drives Rolldown or Rspack behind a pluggable `TransformEngine` interface. Wall-clock time scales as `|changed_alive_modules| / cores`. Dead modules never reach this component.

The warm-rebuild path: change one file, re-summarize it (sub-millisecond), confirm no structural changes (skip Phase 2), transform one module. Everything else is a cache read at memory speed.

## What linkers already proved

JavaScript bundling and native-code linking are structurally isomorphic. The linker world solved the equivalent scaling ceiling between 2019 and 2022. Cloudpack maps their innovations directly.

| Linker Innovation | What It Proved | Cloudpack Equivalent |
|---|---|---|
| **ThinLTO** | Per-module summaries are sufficient for cross-module optimization. Full IR never needs to be in memory simultaneously. | The Summarizer. `ModuleSummary` carries call edges, side-effect markers, reachability data. Same role as LLVM's `FunctionSummary`. |
| **mold** | LLD's bottleneck was serial data-structure contention, not computation. Concurrent hash maps fixed it. | Parallel summarization via `rayon`. One task per file, zero shared mutable state. |
| **BOLT / Propeller** | Static heuristics lose to measured runtime call patterns for code layout. C³ clustering outperforms compile-time guesses. | PGO chunk grouping. Real browser sessions drive chunk layout, no rebuild required. |
| **Incremental linking (mold)** | If the tool is fast enough, the OS page cache makes re-running free. Complex on-disk incremental state is overhead. | At 2KB per summary, re-summarizing unchanged modules is cheaper than deserializing incremental state files. |
| **Dynamic linking (ld.so)** | Late-bound resolution. Load only what's referenced. Share across processes. | The Adaptive Bundle Service. The service worker is `ld.so`. Content-hashed CDN chunks are shared libraries. |

ThinLTO is the key precedent. Before it, LLVM loaded every module's full IR into memory for link-time optimization. At large scale, this was impractical. ThinLTO proved that lightweight per-module summaries are sufficient for correct cross-module decisions. Cloudpack applies the same proof: you do not need to parse 50,000 source files to make correct bundling decisions. Parse them once, cache the 2KB summaries, operate on summaries after that.

## One graph, four views

The module graph is the center of gravity. Every output form is a materialization of the same data.

<div class="breakout">
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 840 380" role="img" aria-label="Diagram: One graph, four views. Source files are summarized into a persistent module graph, which materializes into dev server, CI artifact, production bundle, and adaptive delivery.">
  <rect width="840" height="380" fill="#F5F0E8" rx="4"/>
  <text x="420" y="30" text-anchor="middle" font-family="Georgia, serif" font-size="16" font-weight="bold" fill="#2B2421">One Graph, Four Views</text>
  <rect x="30" y="145" width="120" height="60" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="90" y="170" text-anchor="middle" font-family="monospace" font-size="11" fill="#2B2421">50,000</text>
  <text x="90" y="188" text-anchor="middle" font-family="monospace" font-size="11" fill="#2B2421">source files</text>
  <line x1="150" y1="175" x2="238" y2="175" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a2d)"/>
  <text x="194" y="167" text-anchor="middle" font-family="Georgia, serif" font-size="10" fill="#A0522D">summarize</text>
  <rect x="245" y="135" width="200" height="80" rx="8" fill="#2B2421" stroke="none"/>
  <text x="345" y="165" text-anchor="middle" font-family="Georgia, serif" font-size="15" font-weight="bold" fill="#F5F0E8">Module Graph</text>
  <text x="345" y="183" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">persistent · content-addressed</text>
  <text x="345" y="199" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">~100 MB at 50k modules</text>
  <line x1="445" y1="152" x2="563" y2="78" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a2d)"/>
  <line x1="445" y1="163" x2="563" y2="146" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a2d)"/>
  <line x1="445" y1="187" x2="563" y2="214" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a2d)"/>
  <line x1="445" y1="198" x2="563" y2="282" stroke="#2B2421" stroke-width="1.5" marker-end="url(#a2d)"/>
  <rect x="570" y="52" width="235" height="52" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="687" y="74" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#2B2421">Dev Server</text>
  <text x="687" y="92" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">native ESM from summaries</text>
  <rect x="570" y="120" width="235" height="52" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="687" y="142" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#2B2421">CI Artifact</text>
  <text x="687" y="160" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">incremental · changed modules only</text>
  <rect x="570" y="188" width="235" height="52" rx="4" fill="none" stroke="#2B2421" stroke-width="1.5"/>
  <text x="687" y="210" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#2B2421">Production Bundle</text>
  <text x="687" y="228" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">chunked · tree-shaken · minified</text>
  <rect x="570" y="256" width="235" height="52" rx="4" fill="none" stroke="#A0522D" stroke-width="1.5"/>
  <text x="687" y="278" text-anchor="middle" font-family="Georgia, serif" font-size="13" font-weight="bold" fill="#A0522D">Adaptive Delivery</text>
  <text x="687" y="296" text-anchor="middle" font-family="monospace" font-size="10" fill="#A0522D">per-client delta · PGO-driven</text>
  <line x1="60" y1="332" x2="780" y2="332" stroke="#2B2421" stroke-width="0.5"/>
  <text x="420" y="356" text-anchor="middle" font-family="Georgia, serif" font-size="13" fill="#2B2421">The graph is the truth. Every output is a derived view. No divergence.</text>
  <defs>
    <marker id="a2d" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
      <polygon points="0 0, 8 3, 0 6" fill="#2B2421"/>
    </marker>
  </defs>
</svg>
</div>

The dev server reads summaries and serves native ESM directly. CI produces incremental artifacts by transforming only changed, alive modules. Production emits chunked bundles through the full transform engine. The Adaptive Bundle Service computes delta manifests per client, sending only chunks the browser doesn't already have.

Same graph. Four queries. A bug in dev is a bug in prod because both derive from the same truth.

## The receipts

Benchmarks run against synthetic codebases generated from the statistical fingerprint of real production code: file sizes, dependency fan-out, side-effect density, directory structure. Same seed produces byte-identical output. [Reproducible](https://github.com/kenotron-ms/cloudpack).

### Analysis pipeline (summarize + analyze, no transform)

| Modules | Cold (ms) | Warm (ms) | Speedup | Graph (ms) |
|--------:|----------:|----------:|--------:|-----------:|
| 100 | 19 | 3 | 6.3x | 0 |
| 500 | 73 | 27 | 2.7x | 3 |
| 1,000 | 141 | 58 | 2.4x | 7 |
| 5,000 | 694 | 297 | 2.3x | 38 |
| 10,000 | 1,363 | 604 | 2.3x | 84 |

On a warm rebuild (one file changed out of N), N-1 modules are sub-millisecond cache reads. At 50,000 modules, projected via linear regression: **604ms warm, 11x faster than cold.**

### Full pipeline (with transform)

| Modules | Cold | Warm +1 change | Speedup |
|--------:|-----:|---------------:|--------:|
| 100 | 20 ms | 15 ms | 1.3x |
| 500 | 131 ms | 79 ms | 1.7x |
| 1,000 | 262 ms | 172 ms | 1.5x |
| 5,000 | 1,306 ms | 897 ms | 1.5x |
| 10,000 | 2,770 ms | 1,845 ms | 1.5x |

Full-pipeline speedup is modest (1.5x vs 2.3x) because the transform engine re-processes every alive module regardless of cache. That's the current bottleneck, and the architecture makes it solvable: the transform is pluggable, and the summary cache already identifies exactly which modules are alive and changed. The work is bounded by `O(Δ_alive)`, not `O(n)`.

The next post covers what those 2KB summaries actually contain: [50KB of source compressed 25x into metadata](/posts/50kb-down-to-2kb-why-we-stopped-parsing) that carries everything the graph analyzer needs, and why that compression ratio is what makes the rest of the architecture possible.