Track mcppls and clangd OKE/OKB performance, evidence and release exception

Start with the linked engine PR16, server PR75, and mcpp#885, then read the engine changelog and ci/performance-policy.md cited in the issue. The release work is underway and the issue explicitly defers optional performance experiments; follow the tagged release build and final server UX qualification. Done means the released payload and server UX qualification meet their stated gates, with any remaining performance work tracked separately.

The mcppls server and clangd engine OKE/OKB paths have a remaining cold CPU-efficiency gap and distinct cold/warm user-experience tradeoffs. This issue retains the investigation and tracks optimization after the current ecosystem release. A bounded Linux x64 cold-CPU exception for engine 0.0.20 was approved on 2026-11-06; its accounting repair and bounded CI policy are implemented in merged engine PR16. Product-source CI passed the strict Linux x64 target without using the exception; the tagged release build is underway.

Tracks mcpp#885, engine PR16 and server PR75.

Implementation update, 2026-11-06

Engine PR16 now contains
version-3 accounting and the bounded release policy, on producer source
8ba2350b6b4cdcad2ccdb18dfbf5b177afb8afa3. The final production
build-test 42155475833
passed the four native builds, both Ubuntu 20.04 runtime floors, four OpenKal
acceptances and four warm-prime gates on the public platform 0.24 source group.
Linux x64 cold CPU was 1.109 of native: target_met=true,
release_exception.applied=false. macOS cold readiness had one 1.239 outlier,
then passed at 0.963 on a single-job rerun under the unchanged 1.15 limit;
two earlier runs had passed at 1.075 and 1.080. This establishes product-source
qualification, not yet the tagged release asset or final server UX qualification.

The engine changelog
and release policy
disclose the exception and Windows tradeoff. Local validation passes 23
accounting/acceptance tests and six existing release-gate controls, plus
actual workflow tag/version rejection and release-note extraction controls.
The server changelog and English/Chinese release instructions are prepared
in its existing PR worktree for the final dependency/candidate update.

The diagnostic artifact identities and historical failures below remain
unchanged. New optional performance experiments are deferred until after
this ecosystem release; the issue remains open.

Scope and exact inputs

This issue covers the mcppls server image, its OKB container, the clangd
engine image/container, and the server-to-engine interaction. Measurements
of one are not automatically attributed to another.

Input	Source / SHA256
Measured server source	b70ddaee80bfae3c6042242183ef7fa47043a3e9, producer42021324231
Native server	1b3a7f46bba4f60647d0110490ec702631d2b3646faab2e826ea5d4cee10d275
Server OKB	77c573eca50734176afc5d2a7260a61c9ecaf50bf2fa53f59039b09d41a8e09d
Server x64 OKE	75957a885481186102d71e26f97874cf513edf9a7daa437305c055336f8e71fa
Measured engine source	a13953808f4ec4704288adca3ae095ba858bce86
Native x64 engine	176b8da15867a90edf3059ba4ad384920953839477df49f8e2249cce825f3c72
Engine OKB	72fe2ebb7558ff2bdd5dae2f1bccf65ae2357dff6bcf21d73258a2991bde0e25
Engine x64 OKE	d5ca23a3b536c833b1cf3383b4603b6084ce5eba8be101613f43886bffdb9b3d

The server x64 OKE was independently verified byte-for-byte against the
corresponding OKB member. There is no completed server-only raw-OKE/OKB
container performance comparison; the engine container experiment below
does not establish that result for the server.

Server and engine combinations

The current server and engine completed a native/image × native/image input
control: four combinations, one cold and one warm session each, all 24 target
checks passing. Each cold session built three modules; each warm session
reused the standard-library module and built zero new modules. Actual server
and engine processes matched the declared identities, all 7192 payload files
and 303 shared resource files were rehashed, and no process still referenced
the dedicated payload after normal shutdown.

The following values are one preflight per combination, not repeated
performance estimates. First navigation is measured from session start and
includes initialization. Fixture cache-drain waits are not navigation time.

Server / engine	Cold initialize	Cold first navigation	Warm initialize	Warm first navigation
native / native	0.326 s	2.420 s	0.038 s	0.373 s
image / native	0.386 s	2.347 s	0.044 s	0.431 s
image / image	0.705 s	2.682 s	0.077 s	0.531 s
native / image	0.620 s	2.886 s	0.073 s	0.435 s

These runs restore a valid basis for server overhead experiments. They do not
prove a general server-image slowdown or speedup, complete the larger UX
suite, or qualify the release. Both image factors use the current server's
platform 0.23.5 runner, SHA256
cced088b6d2d8981d12aa3ec7ffec9a81db77b5f41a2b6e2131f532397dd382a.
It is a different build from the platform 0.23.7 engine-only diagnostic runner.

The first attempted assembly selected the old locked engine despite the
native path input and was stopped by its 120 s guard before any scenario ran.
That failed preparation is retained, not counted as performance data. The
successful counterfactual payloads passed the unchanged official verifier;
they were never substituted into the production lock or admission ledger.

User impact and current release boundary

The outstanding Linux x64 failure is a cold CPU-efficiency budget, not a
failure to produce diagnostics, a deadlock or a demonstrated correctness
failure in the measured workload. It does not mean every operation is 20%
slower. The workload has 304 translation units, three opened probes and one
cold plus three warm sessions. Cold means an empty project module cache,
not a globally flushed OS page cache.

The exact a139 producer
41954537459
completed all 32 native/image semantic sessions across four hosts. Its only
warm-prime threshold failure was Linux x64 cold CPU. The independently
downloaded artifact ZIPs passed SHA256 and CRC checks. These are historical
measurement version 2 results; final production must use the corrected
version 3 accounting rather than treating these old reports as current
qualification.

Host	Cold ready, native → image	Cold CPU ratio	Warm ready, native → image	Warm CPU ratio
Linux x64	8.798 → 8.006 s	1.197	2.875 → 2.946 s	1.058
Linux ARM64	6.350 → 6.191 s	1.097	2.399 → 2.405 s	1.022
macOS ARM64	11.031 → 11.862 s	1.026	3.079 → 2.916 s	1.103
Windows x64	11.667 → 16.534 s	1.169	9.361 → 5.344 s	0.566

Linux x64 cold CPU is 12.71 → 15.22 CPU seconds, an increase of 2.51 CPU seconds
or 19.7%. Its wall-clock readiness was lower in that particular run; this is
not a claim that image readiness is always faster. Later corrected-meter
fixed pairs have cold CPU ratios 1.173 and 1.112, with readiness ratios 0.946
and 1.087, respectively.

Windows has a real cold-readiness tradeoff in this test: about 4.87 s longer,
while warm readiness is about 4.02 s shorter. The native Windows engine uses
in-process module compilation and per-reader copies; the image uses owned
cache and supervised workers. Those paths differ, so the existing gate
records their ratios without treating them as equivalent-path performance
parity. This does not make the observed cold user-visible delay disappear.

Interactive latency remains a separate qualification requirement. A traced
joint server experiment observed module validation at 350 ms native versus
828 ms image in one matched pair, with image foreground runqueue delay around
405–421 ms. A second native control did not enter the target phase. This is
diagnostic evidence of a potential scheduling issue, not a production-wide
latency estimate or a completed UX qualification. The final server UX suite
must still pass on the released payload.

Evidence ledger

The rows below distinguish mechanisms, negative candidates and observations.
Costs from different machines and measurement scopes are not added together.

Experiment	Established result	Decision
Frozen input controls	Exact native/image hashes, 303 resource files, actual frontend identity and original workload checked; early mismatched-resource batches remain invalid	Reuse the frozen pair for diagnosis; do not credit invalid runs
Redundant realpath property query	An unnecessary preflight was removed with optional-entry/error/output-bound controls; component improvement did not establish full-engine parity	Already corrected; no path-answer cache
Linux worker supervision	A published process-group filter avoids reading unrelated PID records. Same-host controls reduce auxiliary-thread system CPU while retaining memory enforcement and termination	Adopt the published correction; do not disable supervision
Readiness accounting	A legal child-reap race double-counts 0.480 s against complete wait4 of 0.263422 s; stable-reap version 3 fixes this and includes waited grandchildren	Integrate the validated meter repair; historical failures are not retroactively erased
OKB versus its exact raw OKE	Removing the container did not improve either fixed cold CPU pair	Container removal is not an adopted fix
Snapshot/prefetch controls	Disabling worker prefetch saved 278.796 ms startup CPU but added 248.136 ms in the body on one hosted control; another paired control had no net gain	Do not adopt blanket prefetch-off
User PMU counters	One local fixed cohort retired 6.359% more user instructions and used 3.124% more user cycles; overall CPI was lower	Extra work exists; not evidence of globally worse branch prediction
Matched hash functions	Four verified native/image hash entries totaled 6.082B versus 5.634B represented parent instructions	Absolute hash hotspots are not the main positive instruction difference
Uniform REP memset	Complete-workload cold CPU mean 5.145 → 5.185 s	Rejected; no dependency rebuild
Lexical path shortcut	Semantic controls passed; cold CPU mean 5.0425 → 5.165 s	Rejected; no dependency rebuild
Per-import CPU timing	Timing about 20 million cached context-identity calls materially perturbed the workload. Excluding that timing left about 0.30 s of measured worker imports, including meter cost	Useful interface-family observation, not native/image overhead
Corrected readiness cohort	42136977288, EPYC 7763: child CPU increase 0.91–1.01 s, 77–87% in kernel CPU; one of two cold pairs still fails 1.15	Performance target remains unmet
Worker phase closure	42147444111, EPYC 9V74: child system increase 0.60/0.46 s. Startup contributes 0.254/0.217 s, body including native callbacks 0.216/0.135 s, unaccounted report/exit tail 0.130/0.108 s	Prioritize startup while retaining body and exit accounting
Actual instruction pages	One complete cold session captured 177 process profiles. The original note names 305 blocks of 64 KiB; median worker executes 150 blocks, parent executes 304 of the 305 named blocks	One shared prefetch hint covers materially different process roles
Common-worker note candidate	Only the advisory note was changed to 150 blocks; code, layout, other architecture and resource policy unchanged. 32 sessions/1408 workers pass. Worker system mean 0.795 → 0.7425 s, whole cold CPU 5.1925 → 5.2275 s, warm CPU 2.235 → 2.195 s	No whole-cold gain established; not adopted or shipped
Joint UX scheduling	One valid traced pair shows larger foreground queue delay; background scheduling policies differ. Second matched pair is incomplete	Keep as a separate hypothesis; final untraced UX remains required

The delivery comparison also contains toolchain/library differences: the
frozen native producer uses Clang 12 and static libstdc++, while the image
uses Clang 23.1.3 and libc++. It is valid as a product comparison, but not a
single-variable measurement of OpenKal's cost.

Approved exception for the current release only

The long-term target stays 1.15. The release exception was approved on
2026-11-06 with all the following conditions. Implementation is pending at
issue creation; no historical failed run is retroactively relabeled.

Property	Approved rule
Release	mcppls-clangd 0.0.20 and the mcppls release carrying those exact published engine bytes
Host/metric	Linux x64, cold readiness CPU only
Relative ceiling	Image/native cold CPU ≤ 1.25
Absolute ceiling	Extra cold CPU ≤ 3.0 CPU seconds in the unchanged 304-unit fixture
Unchanged performance gates	On the existing gated hosts: cold/warm wall readiness ≤ 1.15; warm CPU ≤ 1.15; other gated hosts' CPU ≤ 1.15; complete-lifetime faults ≤ 2.0
Unchanged correctness gates	Every semantic session, owned-cache/worker path, resource enforcement, cancellation, crash handling, packaging and final server/editor UX
Measurement	Corrected version 3 stable-reap accounting; original workload and raw sessions retained
Reporting	Preserve target_met=false when 1.15 is missed. Record the explicit release exception separately, with issue, release and exact artifact identities
Expiry	Current release only. The next engine version defaults back to 1.15; extending an exception requires a new review
Refusal	Any failed correctness/UX gate, invalid measurement, or either exceeded ceiling still blocks release; no automatic upward adjustment

The 1.25 ceiling is a bounded release deviation, not a conclusion that 25%
overhead is desirable. A 1.20 ceiling leaves almost no margin around the old
1.197 result and is below a separately preserved 1.224 diagnostic result.
Final coherent dependencies may behave differently and still require one
fresh production qualification. The current generic --limit controls both
readiness and CPU in both cold and warm cases; raising it globally would be
broader than this proposal and is not the intended implementation.

The Windows cold/warm tradeoff and any remaining debugger-frontend limits
remain visible in release notes. This CPU exception does not waive an SDK
runtime failure, untested behavior, or a failed joint UX scenario.

Follow-up experiments after the ecosystem release

1. Separate useful instruction prefetch from repeated unused work per process
   role. Retain the parent body's and teardown's costs. The shared narrowed
   note is a negative result, not a production candidate.
2. Match native and image file-operation families and page-fault work in the
   largest remaining stage. Compare equivalent operations rather than one
   syscall name or absolute API totals.
3. Evaluate foreground/background scheduling with an actual intervention,
   preserving worker limits, cancellation, isolation and correctness. Keep
   this distinct from the background-index-disabled CPU fixture.
4. For the server, repeat the controlled four-combination experiment and
   align request arrival, proxy queueing, engine work, fallback and authoritative
   response timestamps. Measure raw OKE versus the same OKB member separately.
   Do not extend the engine container result to the server.
5. Use matched small components to isolate toolchain, standard-library,
   allocator and context-lookup contributions before any further LLVM rebuild.
6. Consider bounded worker reuse or same-system image interaction only after
   a measured startup contribution and lifecycle/reset/failure contracts
   justify it. mcpp retains generic build semantics; engine protocols belong
   to the engine and platform primitives to OpenKal.

Close this issue only after representative and held-out workloads pass the
original 1.15 target on final exact artifacts, or after an explicitly reviewed
long-term performance specification replaces it. A release exception alone
does not resolve the performance issue.

Publication and privacy

Publish sanitized summaries, exact source/artifact identities, public CI URLs,
measurement scopes, failed controls and negative results. Keep raw customer
IDE logs, user names, private project names, local directory paths and memory
contents out of the issue, attachments and PRs. Retain the local evidence
archive and generic diagnostic scripts so the summary remains auditable.