2.2.4 Skymeld
extraSkymeld is Bazel's name for letting execution start as soon as some top-level targets finish analysis, instead of waiting for analysis of the entire request to finish first. In the textbook model from 2.2.1 Loading, Analysis & Execution, analysis hands execution one big batch. Skymeld keeps the same responsibilities but removes more of that barrier, which matters mostly on multi-target builds where one slow-to-analyze target would otherwise keep ready work idle.1,2,3
A, B, and C all wait until request-wide analysis finishes.
A and B execute while C still analyzes.
Why it exists
Classic phase separation can leave CPUs idle near the end of analysis: some top-level targets are already fully analyzed, but Bazel still waits for the stragglers before starting any execution. Project Skymeld was created to use that waiting time by launching execution for each top-level target as soon as its analysis result is ready.1 That is why the biggest wins show up in multi-target builds with a long-tailed analysis step, not in a single-target build where there is little or no cross-target waiting to hide.1,2
Bazel 6 introduced Skymeld as the experimental --experimental_merged_skyframe_analysis_execution mode. Bazel 7 turned that behavior on by default, so in practice the remaining knob is opting out for benchmarking or bug workarounds.4,5,6
What it changes, and what it does not
The important change is scheduling, not the reader-facing vocabulary. Loading still discovers packages, analysis still configures targets and actions, and execution still runs actions to produce artifacts. Bazel just overlaps more of that work internally than the clean classroom picture suggests.3 That is why the phase model from 2.2.1 Loading, Analysis & Execution and the log-reading habit from 2.2.2 Reading Build Output are still useful even after Skymeld exists.
Skymeld is also not a rebuttal of 2.2.3 Static Action Graph. Ordinary rules still do not get to run tools, inspect generated files, and invent the normal build graph on the fly. The dedicated Skymeld work was instead about continuing from per-target analysis straight into execution and moving between-phase checks, such as action-conflict checking, into incremental forms that can consume results as they arrive.1 The mental model is: same build responsibilities, less idle time between them.
When you notice it
When Skymeld helps, you usually notice it as shorter wall time, not as a different BUILD-language experience. The gain depends on build shape and top-level target count, with reported reductions up to roughly 15% on suitable builds.2,6 If one top-level target has much more expensive analysis than its siblings, Skymeld lets the siblings start doing real execution work instead of waiting at the old phase boundary.1,2
If you are comparing invocations, remember that "Skymeld enabled" is a versioned performance feature, not a universal explanation for every build-speed change. Bazel 7 changed several other performance-sensitive areas too, including profiling, caching, and remote behavior.5
If you inspect profiles later
The merged behavior shows up most clearly in performance tooling. Bazel 7 added an ANALYZE_AND_EXECUTE phase in timing profiles, and profiling tools such as the Bazel Invocation Analyzer can read Skymeld-enabled traces and even suggest enabling Skymeld when it is off.5,6 5.4.1 Timing Profile Analysis and 5.4.5 Bazel Invocation Analyzer (BIA) cover those tools later. For Level 2, the important point is just that the overlap is real enough to change profiling output.
Skymeld does not abolish Bazel's three responsibilities. It relaxes the pause between them: once some top-level targets are fully analyzed, Bazel can start executing their ready actions instead of waiting for every sibling target to finish analysis first. That helps most on multi-target builds with long-tailed analysis, and it is why the old phase story is still useful for reasoning even though Bazel's engine overlaps more work internally now.1,2,3
Check your understanding · 3 questions
1.What class of build gets the most wall-time benefit from Skymeld?
Select one answer
2.True or false: what Skymeld changes and does not change.
Choose True or False for each sentence
3.While inspecting a JSON timing profile from a recent Bazel build, an engineer sees an ANALYZE_AND_EXECUTE segment instead of a clean split between an analysis phase and an execution phase. What is the right way to read that?
Select one answer
Footnotes
-
How to speed up your Bazel builds with Project Skymeld — why multi-target long-tail analysis creates idle time, per-top-level execution after analysis, and incremental conflict checking ↩1 ↩2 ↩3 ↩4 ↩5 ↩6
-
How Bazel 7.0 Makes Your Builds Faster — merged analysis/execution as a Bazel 7 speed feature whose benefit depends on build shape and top-level target count ↩1 ↩2 ↩3 ↩4 ↩5
-
Empyrean Evaluation — the "three phases" as a still-useful abstraction even as Bazel overlaps more of the underlying Skyframe work ↩1 ↩2 ↩3
-
What's New in Bazel 6.0 — Skymeld introduced experimentally under
--experimental_merged_skyframe_analysis_execution↩ -
What's New in Bazel 7.0 — Skymeld enabled by default in Bazel 7 and
ANALYZE_AND_EXECUTEadded to timing profiles ↩1 ↩2 ↩3 -
Bazel 7 is here - and Bazel Invocation Analyzer is ready for it! — up to 15% wall-time reduction claim, opt-out form, and tooling support for Skymeld-enabled traces ↩1 ↩2 ↩3
