Rewatch: in-process bsc prototype

[cknitt]

Based on the OCaml rewatch reimplementation from #8653, we can prototype integrating the compiler directly into the rewatch executable to avoid having to spawn a bsc binary for each compilation step.

@cristianoc fed the prompt below into Fable, and I fed the same one into Astra.

I'll post the responses we got as separate comments. These can serve as a basis for further discussion.

We are porting Rewatch to OCaml as a drop-in for the Rust version. Next I want to see whether in-process bsc is worth it: stop spawning a bsc process per module, and ideally stop writing cmj/cmt (and maybe cmi) to disk at all.

Do not implement yet. Think this through with me.

Context:

• A lot of build time is process creation and artifact I/O, not typechecking.
• Integration might be >2x. I want a dirty prototype that measures that, even if it is incorrect and single-threaded.
• The compiler has lots of global/shared mutable state (Clflags, Config.load_path, Env cache, Ident, Js_config, typechecker mutation, etc.). There are essentially no tests that reuse one compiler process across modules.
• Getting rid of global state is probably much easier than the Rewatch port, but only if we know what to reset/isolate.
• No multicore required for the prototype. Sequential in-process with no cm* writes may already be faster.
• A real compiler service / parallel-from-one-process comes later.

Please:

1. Survey how bsc is invoked today (parse vs compile), what it reads/writes (ast, cmi, cmj, cmt, js), and which globals would leak across compilations.
2. Propose the smallest prototype that can give a real speedup signal on stdlib + tests (or a real project). What can stay on disk? What must be in memory? What must be reset between modules?
3. Argue whether that prototype is the right next step, or whether something else is better (reset-and-reuse API, keep writing cmi only, compiler service still spawning-free but still on disk, etc.).
4. Explicitly list what is likely to go well, what is likely to go wrong, and how we would get fooled by a misleading benchmark.
5. Recommend a concrete goal we could later implement with /goal.

[cknitt]

Fable: In-process bsc: survey, measurements, and prototype proposal

Date: 2026-09-09. Machine: Apple M2 Max, 12 cores, macOS. Compiler: _build/default/compiler/bsc/rescript_compiler_main.exe at commit d90b96a. Build system: rewatch (Rust) via cli/rescript.js.

Summary

Stop spawning a bsc process per module is worth prototyping. The premise needs one correction: process spawn dominates, artifact I/O does not. A bsc process costs about 7 ms before it does any work, roughly half of that in bsc's own static initialization. For the tests corpus, spawns account for ~9 s of a 10.7 s sequential build; the actual parse/typecheck/codegen work is ~2.4 s of CPU; artifact I/O is under 1 s.

Consequences:

• A sequential in-process build lands near 2.5 s on the tests corpus. That ties the 12-thread rewatch build on this machine (2.15 s) and wins on a 4-core CI box. A >2x win requires parallelism inside one process. The sequential prototype establishes the floor and the reset list needed for that.
• "Stop writing cmj/cmt/cmi" is second-order (<10%) and should be a flag experiment inside the prototype, not the goal. cmt is needed by the editor, gentype and reanalyze; cmi bytes on disk are rewatch's change detector.
• The prototype should be a batch replay mode in bsc that keeps every artifact on disk, with a byte-level artifact diff as the correctness oracle. No rewatch changes needed.

1. Measurements

Every build was preceded by rescript clean. Threads controlled with RAYON_NUM_THREADS. Spawn counts: two per source file (parse to .ast, then compile), interfaces included.

corpus	modules	bsc spawns	12 threads wall	1 thread wall	1 thread user / sys	12 threads user / sys
runtime	106 (+48 resi)	~308	0.58 s	2.42 s	1.10 / 1.12	1.37 / 2.21
belt	43	~86	0.45 s	1.60 s	0.82 / 0.65	0.96 / 1.18
tests/tests	632 (+27 resi)	~1318	2.15 s	10.7 s	5.44 / 4.58	6.70 / 9.13

Per-process cost (averages over 20-50 runs):

command	wall	CPU (user+sys)
/usr/bin/true	1.4 ms	1.0 ms
bsc -version (exits during arg parsing, after all static init)	6.8 ms	5.8 ms (3.0 user, 2.8 sys)
bsc full compile, empty module (loads Pervasives + Stdlib cmi)	7.8 ms	6.6 ms
bsc -bs-ast, 414-line Stdlib_Array.res	11.4 ms
bsc -bs-cmi-only from .ast, Stdlib_Array	14.4 ms
bsc full from .ast, Stdlib_Array	16.2 ms
bsc -bs-ast, 2650-line mario_game.res	17.8 ms
bsc -bs-cmi-only from .ast, mario_game	34.1 ms
bsc full from .ast, mario_game	46.7 ms	43 ms

Derived, tests corpus, 1 thread: 1318 spawns x 6.8 ms = ~9.0 s of 10.7 s wall. CPU: 10.0 s total minus 1318 x 5.8 ms = ~2.4 s of real compiler work. Remaining sys after spawns ~0.9 s: that is the upper bound on artifact I/O.

Artifact volume, tests build: ast 3.4 MB, cmi 2.0 MB, cmj 0.1 MB, cmt 11.9 MB, mjs 0.9 MB.

Parallel spawning is expensive on macOS: 12 threads burn 15.8 CPU-s for 10.0 CPU-s of sequential work (sys doubles under contention). Spawn cost also limits parallel scaling, not only sequential time.

2. How bsc is invoked today

Rewatch spawns bsc directly (Command::new(bsc_path).current_dir(<package>/lib/bs).args(...)), cwd is the package build dir, arguments mostly relative. sh -c is used only for js-post-build, not on the hot path.

Example (tests/tests, rescript compiler-args src/mario_game.res):

parser_args:   -check-lam -w <list> -warn-error A -absname -bs-ast -o src/mario_game.ast ../../src/mario_game.res
compiler_args: -I ../ocaml -runtime-path <abs runtime> -I <abs rescript-react/lib/ocaml> -check-lam -w <list>
               -warn-error A -bs-package-name rescript-tests -bs-project-root <abs> -bs-package-output esmodule:src:.mjs
               src/mario_game.ast

Per module: parse step writes the binary .ast (with a dependency header that rewatch deps.rs reads as lines); compile step reads the .ast. Interfaces get their own parse and compile, run just before the implementation (compile.rs compile_one). Rewatch blake3-hashes the module's cmi before and after the compile; if unchanged, dependents are skipped (is_clean).

Compile-step reads:

• Dependency cmi: Env.Persistent_signature.load hook, set to Bs_cmi_load.load_cmi, which uses Config_util.find_opt = Misc.find_in_path_uncap over Config.load_path: two Sys.file_exists probes per directory per lookup, no cache.
• Own cmi when a .resi exists (-bs-read-cmi): Typemod.type_implementation_more calls find_in_path_uncap and Env.read_signature directly by filename, bypassing the hook.
• Dependency cmj (cross-module arity/inlining): Js_cmj_load.load_unit ref hook, Js_cmj_format.from_file.

Compile-step writes:

• cmi via Env.save_signature / Cmi_format.create_cmi ?check_exists: compares with the existing file and skips the write if unchanged.
• cmt via Cmt_format_persistence.save_cmt (native impl; the playground impl is a no-op). Embeds Sys.argv, cwd, load path, imports.
• cmj via Js_cmj_format.to_file ~check_exists: digest compare, skip if unchanged.
• .mjs/.js (+ .map) via Lam_compile_main.lambda_as_module; then Build_artifact.mark_stale on the .ast if warnings fired (so rewatch re-shows them).

Prior art for one-process reuse: compiler/jsoo/jsoo_playground_main.ml. Its reset_compiler is: warning buffer, Experimental_features.reset, Warnings.reset_fatal, Env.reset_cache_toplevel (keeps loaded cmi structures), then Lam_compile_env.reset and Res_compmisc.initial_env per compile.

3. Global state that would leak across compilations

Top-level mutable cells (ref, Hashtbl.create, etc.): compiler/ml 124, common (Js_config) 27, ext 9, core 7, frontend 2, syntax 0, gentype 21.

A. Command-line configuration, set by arg parsing, never reset

• Clflags: include_dirs, open_modules, all_ppx, output_name, assume_no_mli, dont_record_crc_unit, binary_annotations, bs_gentype, color, dump_* flags, transparent_modules, no_assert_false.
• Js_config: all 27 refs (jsx_, source_map, no_export, cmi_only, cmj_only, force_cmi/cmj, syntax_only, binary_ast, as_pp, debug, directives, all_module_aliases, cross_module_inline, ...).
• Warnings.current options (parse_options is cumulative), Config.load_path, Runtime_package.path, Ext_path.project_root, Js_packages_state.packages_info / make_runtime, Location.input_name, absname.
• Also set from source, not just argv: Ast_config.process_str sets Js_config.no_export and directives from @@config; implementation_map (namespace mlmap) sets Js_config.cmj_only := true permanently. Lam_compile_env.reset already resets no_export because the playground hit this.

B. Per-unit caches that already reset on the existing path

• Res_compmisc.init_path: Config.load_path and Env.reset_cache (clears persistent_structures, crc_units, imported_units, current_unit, decl tables).
• Res_compmisc.initial_env: Ident.reinit (stamp counter back to the post-predef level).
• Lam_compile_env.reset: cached cmj tables.
• Typemod.type_implementation_more: Cmt_format.clear, Delayed_checks.reset_delayed_checks; Ctype.init_def per definition.
• Warnings.reset / reset_fatal / has_warnings and Location.input_name: reset only in the -bs-syntax-only multi-file loop in rescript_compiler_main.ml, not on the compile path.
• To verify: Translmod.export_identifiers / js_hoisted, Lambda_exits counters, Js_source_map.current, Typedtree.idents, Printtyp name tables, Builtin_attributes deprecated tracking.

If the Env persistent cache is kept across modules (playground style), imported_units must still be cleared per unit (it feeds the cmi crc list and cmt imports) while crc_units must be kept, otherwise later cmi files carry missing crcs. Env.clear_imports is not exported today.

C. Typechecker scratch state
Ctype (levels, univar_pairs, trace flags, ...), Typecore, Typetexp, Printtyp, Btype snapshot counters. Reset by their own happy paths; left dirty when an error exception escapes mid-phrase. Monotone counters (Btype.new_id, Subst.new_id) are fine.

D. Process-level state
cwd (rewatch runs each bsc in the package's lib/bs), stdout/stderr, at_exit flush of the error formatter, exit calls in error paths (Bsc_args.bad_arg, reprint paths).

Ident stamps: today each process restarts stamps at the same level, so cmi files from different modules already share stamp ranges; this works because Subst.signature renames bound idents on include/open and persistent module idents have stamp 0. In-process is the same. Serving signatures from memory instead of marshalled copies is different: type nodes are mutable (desc, levels, abbreviation memo) and would be physically shared across consumers. The playground does this, but for one unit at a time.

4. Proposed prototype: batch replay mode

Smallest prototype with a real signal, no rewatch changes:

1. Record invocations. Point RESCRIPT_BSC_EXE at a shim that appends cwd \t argv to a log and execs the real bsc. Run rewatch with RAYON_NUM_THREADS=1 so the log is a valid topological order.
2. -bs-batch <file> in rescript_compiler_main.ml: for each line: Sys.chdir, reset all group-A refs to defaults (add Js_config.reset, Clflags reset, Warnings.reset + reset_fatal + has_warnings := false, Experimental_features.reset, packages state, project root, runtime path), parse args with the existing Bsc_args parser, run process_file, catch exceptions, report, continue. All artifacts still on disk.
3. Measure on runtime, belt, tests, and one real project: batch replay vs the same log replayed by spawning (a 10-line script) vs rewatch at 1 and 12 threads. The spawn replay separates rewatch's own overhead (cmi hashing, dep reading) from the compiler's.
4. Correctness oracle: byte-diff every cmi/cmj/cmt/mjs against a normal build. Any difference locates a leaked global. cmt embeds argv and cwd, so exclude that field.

Then, inside the same prototype, three flag-gated experiments of ~20 lines each:

• (a) -bs-no-bin-annot to measure the cmt share.
• (b) keep the Env cache across modules (reset_cache_toplevel + evict the unit just written + clear imports) to measure cmi reload cost.
• (c) serve cmi and cmj from an in-memory table through the two loader hooks and skip their writes, to measure the "no cm* writes" hypothesis directly.

What stays on disk in step 2: everything. What must be in memory: nothing yet. What must be reset: group A before each arg parse, group B is already handled, group C only matters after errors, group D via chdir and exception-instead-of-exit.

5. Alternatives considered

• Reset-and-reuse API first. Premature: we do not know which state matters; the artifact diff from the batch prototype is what finds out.
• Keep writing cmi only / drop cmt. Second-order by the numbers. cmt is required by analysis (17 files read it), gentype and reanalyze; cmi bytes are rewatch's is_clean mechanism.
• Spawn-free compiler service still on disk. That is exactly the batch prototype minus a pipe protocol; the batch file is the same thing.
• Reduce bsc startup instead. ~3 ms of user time happens before argument parsing (static init, plus dyld of a 14 MB binary). Worth a 30-minute look because it also helps today's rewatch and the editor, but it can at most halve spawn cost, so it does not replace in-process.

6. What will go well, what will go wrong, how a benchmark fools us

Likely to go well:

• The pipeline is re-entrant on the happy path (playground proves it).
• Loader hooks (Persistent_signature.load, Js_cmj_load.load_unit) and compare-and-skip writers already exist.
• The batch driver is under 200 lines; the tests corpus of tiny modules is the ideal showcase.

Likely to go wrong:

• Source-driven flags leaking between modules (@@config, namespace map cmj_only).
• Typechecker scratch state left dirty by the first error; exit calls ending the batch.
• Heap growth over 600 modules: major GC cost may eat part of the gain; measure RSS and GC time.
• Cumulative Warnings.parse_options; per-package differing -w lists.
• Experiment (c): physically shared mutable type nodes across consumers.

How a benchmark would fool us:

• Comparing sequential in-process against sequential spawn (5x headline) instead of the honest baseline, the 12-thread build (a tie here).
• The tests corpus exaggerates fixed cost; a real project with larger modules must be in the table.
• Leaked state can make later modules faster by skipping work (cached cmi, check_exists skips); only the artifact diff catches that.
• macOS spawn cost is far higher than Linux; a Linux number is needed before claiming CI gains.
• Warm page cache and clock drift: alternate A/B order.
• Not cleaning between runs: make lib is stamp-driven and rescript build is incremental; every timed run must follow a clean.
• Counting rewatch's own overhead against bsc: compare batch against the spawn replay of the same log, not only against rewatch.

7. Recommended /goal

Add a -bs-batch replay mode to bsc plus a bsc-logging shim. Deliver a clean-build table for runtime, belt, tests and one real project comparing batch replay, spawn replay, and rewatch at 1 and 12 threads, on macOS and Linux. Deliver a byte-level artifact diff against a normal build with every leaked global listed and reset. Then run the three flag experiments: no cmt, cached Env, in-memory cmi/cmj.

Non-goals: no parallelism, no rewatch changes, no removal of artifact writes in the product path.

Assumption: the OCaml rewatch port is not in this repository; the prototype does not depend on it.

Appendix: housekeeping done during the study

• make test initially failed on stale untracked artifacts from an older compiler: two .res copies under tests/tests/lib/ and 725 gitignored .cm*/.ast files under tests/build_tests/super_errors*/. Only those ignored files were deleted; make test then passed (744 mocha tests).
• packages/@rescript/darwin-arm64/bin/bsc.exe and packages/@rescript/runtime/lib/ocaml were out of sync until make lib; only make refreshes those copies.

[cknitt]

Astra

Yes—this is worth prototyping. I would start with sequential compiler reuse, then remove CMT output and move CMJ into memory. Keep CMI and AST files on disk initially.

That can answer the performance question without first solving mutable type-graph ownership. I would push back on two assumptions:

• “Removing global state is easier than the Rewatch port” is plausible but unproven. Resetting configuration is straightforward; safely retaining compiler objects across modules is substantially harder.
• “No cm files” should be an experimental endpoint, not the first milestone.* Combining everything immediately makes both failures and speedups difficult to explain.

This is based on source inspection of both Rewatch implementations and the compiler. No code changed or benchmarks run.

1. What happens today

Compiler invocations

Both Rust Rewatch and the OCaml port still launch external bsc processes.

For an ordinary module without an interface, a clean build generally has two compiler launches:

1. Parse .res into .ast.
2. Compile .ast into compiler artifacts and JavaScript.

With .resi, there are generally four: parse and compile each source. Namespace .mlmap compilation adds another job. PPX commands can launch additional processes during parsing.

Parsing performs the external PPX and built-in frontend transformations before writing the AST. Compilation reads that transformed AST; it should not run those transformations again. Rewatch reads the AST dependency header to construct its graph.

The relevant paths are Rust parsing, OCaml compiler jobs, and compiler dispatch.

Artifact roles

Artifact	Producer and consumer	Prototype implication
.ast / .iast	Parser writes dependencies, source filename, and marshalled AST; Rewatch reads dependencies; compiler reads AST	Keep initially. Removing parser processes does not require removing AST files.
.cmi	Interface compilation, or implementation with inferred interface; downstream typechecking reads it	Keep initially. Preserves signature copying, import digests, and interface checking.
.cmj	Backend exports metadata; downstream backend reads it	Must replace its contents, not simply omit it.
.cmt / .cmti	Typed annotations; consumed by editor analysis and GenType; build system also tracks artifact existence/timestamps	Can omit for a restricted clean-build experiment. No need to retain typed trees in memory unless serving those consumers.
JavaScript / source maps	Backend output consumed by the project	Keep writing and validating them.

CMJ matters even with cross-module inlining disabled. It carries information used for arity, dependency effects/purity, package/import resolution, and hoisted exports, as well as optional inlineable code. See CMJ consumers.

There is also driver-side I/O: artifact publication into lib/ocaml, source copies, and sometimes JS copies. Removing compiler writes alone does not remove all artifact traffic.

Existing reuse support—and its limits

There is already some deliberate reuse machinery:

• Res_compmisc.init_path rebuilds the load path and calls Env.reset_cache.
• initial_env calls Ident.reinit.
• Lam_compile_env.reset clears backend dependency state.
• Implementation typing clears CMT accumulation and delayed checks.
• Translmod.transl_implementation clears exports and hoisted-function accumulation.

See compiler initialization.

The playground also repeatedly compiles in one process. That is useful precedent, not evidence of arbitrary multi-package build safety: its reset retains persistent environments and it bypasses parts of native compilation. Its reset_compiler comment promises more than the short reset establishes for this use case. See playground reset.

2. State that needs isolation

The useful distinction is per-request configuration, disposable compilation state, and intentionally retained dependency data.

State	Required treatment
Clflags, Js_config, experimental features, warning options	Restore an initialized baseline before every parse, interface, implementation, and namespace job, then apply that job’s arguments.
Package name/output specifications, namespace opens, runtime path, project root, GenType configuration	Reset alongside flags. These are not all owned by Clflags.
Load path, current unit, Env persistent and lookup caches, imports/CRC bookkeeping	Initially use the full native reset for every compilation. Do not retain Env objects just to obtain a faster number.
Warning counts, has_warnings, delayed checks, CMT accumulation, diagnostic filename/source state	Clear at request boundaries, including boundaries between interfaces and implementations.
Typechecker levels, abbreviation caches, mutation trails, copy sessions, pattern/type-variable state	Audit successful-path invariants and reset or assert them explicitly. Error recovery needs additional work.
Identifier/type-node counters	Do not indiscriminately rewind counters while retaining objects containing those identities.
Backend per-module caches and accumulators	Reset; keep any new build-wide artifact store separate.
Installed callbacks, printers, frontend handlers	Initialize once. They are wiring, not disposable request state.

There are concrete failure cases already visible:

• Parse leaves syntax_only and binary_ast enabled.
• Namespace compilation sets cmj_only, which could suppress the next module’s JS.
• -bs-read-cmi can leak into a module without an interface.
• Package-output flags accumulate; repeated package-name setup can raise “duplicated flag.”
• File-level compiler attributes mutate configuration.
• Warnings.reset does not itself clear every warning-related accumulator.
• Delayed checks restore warnings and backtrack on the normal path; an exception can interrupt that cleanup.

For the first prototype, abort the entire build on the first compiler error. That avoids pretending to support recovery while still testing successful sequential reuse.

3. The smallest useful experiment

I would implement one experimental clean-build runner with staged modes, using the existing OCaml build plan and argument generation.

It should run parse jobs in-process, retain the current dependency graph construction, then execute namespace/interface/implementation jobs sequentially in dependency order. Extract a thin callable driver from the executable’s argument handling and dispatch; do not design a comprehensive compiler-service API yet.

Modes

Mode	Compiler execution	Artifacts
A	External processes, sequential	Current outputs
B	In-process, sequential	Current outputs
C	In-process, sequential	CMI + CMJ + AST + JS; no CMT/ CMTI
D	In-process, sequential	CMI + AST + JS; CMJ in memory; no CMT/ CMTI

Also measure the existing normally parallel Rust and OCaml builds. A–D explain the mechanism; those normal builds establish practical value.

Why D is the useful target

What stays on disk: sources/configuration, ASTs, CMIs, JS/maps, and prebuilt external dependencies.

What must be retained in memory: CMJ data for modules compiled during this build, including their package identity/path.

What does not need retaining: CMTs, typed trees, completed modules’ typing environments.

CMJ already has a replaceable loader, Js_cmj_load.load_unit. Its producer has a concentrated write point in Lam_compile_main.compile. These are promising seams.

The store must honor load-path resolution and package identity. A global module_name → CMJ table is insufficient when different packages expose the same name. For modules rebuilt in the experiment, forbid fallback to stale disk CMJs; allow disk reads only for explicitly external dependencies.

CMT output already has -bs-no-bin-annot. But the experimental driver must accommodate missing annotations: normal publication and freshness logic expect them in places. GenType workloads need a separate configuration retaining annotations, or explicit exclusion.

Why keep CMI?

Removing CMI involves more than replacing the ordinary dependency loader:

• Explicit-interface checking performs a filesystem lookup and signature read.
• Signature saving copies through Subst.for_saving and maintains import digests.
• Retaining live signatures introduces mutable graph sharing.
• Ident.reinit complicates retention of objects with local identifiers.

The relevant boundaries are signature saving and implementation/interface checking.

If CMI later looks expensive, the next experiment should be serialized CMI bytes in memory, decoded into fresh objects, preserving existing persistence semantics. Direct live-signature sharing can come afterward.

4. Is something else a better next step?

A narrow reset-and-reuse boundary is part of this prototype. A comprehensive global-state refactor is not a prerequisite.

My preference:

1. Establish B: reuse with existing disk behavior.
2. Measure C and D as incremental changes.
3. Investigate CMI or AST memory only if remaining measurements justify it.

A persistent worker process would also eliminate per-module launches, and could eventually provide crash isolation. But for an OCaml caller it adds a protocol and lifecycle management without being necessary to answer the first question. Keep it as an architectural option.

Batching parse invocations is a cheaper alternative—the CLI already permits multiple syntax-only inputs—but varying output arguments and file-level state still need care. It measures only part of the opportunity.

I would reject the prototype only if it starts growing into a general service, watch-mode redesign, or mutable-signature cache before producing B–D timings.

5. What should go well, what may go wrong

Likely to go well

• Compiler libraries are already separately linkable.
• Existing resets provide a substantial starting point.
• Removing both parse and compile launches should particularly help many small modules.
• Suppressing annotations avoids serialization, source digest reads, and publication work.
• CMJ loading already has a hook.
• Sequential execution avoids concurrency hazards while exposing cross-request leaks.

Likely to go wrong

• Configuration leaks silently skip work or change outputs.
• Package/path-sensitive caches resolve the wrong dependency.
• Long-lived heaps increase GC cost and retained memory.
• CMJ payloads containing compiler IR expose identity or mutation assumptions.
• Failed typing leaves state unusable for subsequent jobs.
• GenType, editor artifacts, warning replay, and incremental freshness stop matching the drop-in contract.
• Sequential execution loses enough parallelism to outweigh process savings.

I would allow rough architecture and a restricted workload. I would not allow silently missing modules or wrong JS to count as a speedup.

How the benchmark could fool us

The main traps:

• Comparing sequential reuse only against sequential subprocesses, while users run parallel builds.
• Timing compilation after parsing was done outside the timer.
• Counting omitted GenType, annotations, source maps, or publication as “process savings.”
• Loading stale artifacts from an earlier build.
• Reusing a warm compiler heap for the candidate while restarting the baseline.
• Measuring tiny modules exclusively, then generalizing to typechecking-heavy projects.
• Using summed child CPU time as though it were parallel wall time.
• Running filesystem tracing during the timed benchmark.
• Calling page-cache writes “physical disk cost.”
• Timing make test as one block, obscuring build changes with unrelated test execution.

Reuse the existing benchmark methodology, but replace equal-process-count checks with equal logical-job checks.

Measure interleaved release builds in isolated trees, including startup and shutdown. Report:

• End-to-end wall time and phase timings.
• Logical parse/interface/implementation/namespace job counts.
• CPU time, peak memory, allocation and GC time.
• Artifact reads/writes and bytes, collected separately from timing.
• JS file-set and byte comparisons, plus execution of the generated tests.

Use stdlib + the compiled test project, and preferably the previously measured large real project. Distinguish rebuilding stdlib from consuming it prebuilt.

6. Recommended later /goal

Build an opt-in, sequential, clean-build experiment in the OCaml Rewatch port that reuses the native compiler for parsing and compilation. Measure external sequential execution, in-process execution with existing artifacts, annotation suppression, and in-memory CMJ with CMI and AST retained on disk. Preserve generated JavaScript and logical compiler work on stdlib and the test project, and measure one representative real project if available. Compare against normal parallel Rust and OCaml builds. Report wall time, memory/GC, artifact traffic, output equivalence, and known state-isolation limitations. Abort on compiler errors; exclude watch recovery, multicore, and in-memory CMI. Finish with a recommendation based on the measured gains.

Success is a trustworthy decision, not necessarily 2×. A large B improvement validates reuse; a large C/D improvement validates artifact work. A disappointing D result tells us whether CMI/AST costs justify another experiment.

The relationships inspected were parse-to-dependency extraction, interface-to-implementation checking, CMJ-to-backend behavior, and annotations-to-tooling/build bookkeeping. They support this staged approach; a complete reset inventory and safe retention of live compiler graphs remain unverified.