Repository navigation
Reuse a complete runtime verification between builds - #48
Merged
Merged
Conversation
Every build, status check and self-test compile rehashed all ~3,982 runtime files (~372 MB), which was most of a warm build and the largest main-process CPU consumer. inspectRuntime now reuses a complete verification while the exact pin, the file set and every file's identity (dev, inode, size, mode, nlink, ns mtime/ctime) are unchanged, for at most ten minutes. Any change, a new process, a failure or an expiry rehashes every byte. Install, repair, pack assembly and installer checks keep the always-complete verifyRuntime. Preparation also streams installer files through a bounded buffer instead of reading whole engine binaries into memory. Claude-Session: https://claude.ai/code/session_01BgdVQjEFKCM4UR2MTytQgv
grawish
force-pushed
the
perf/runtime-verification-reuse
branch
from
October 15, 2026 19:51
6ea9378 to
bcfdc67
Compare
First-run preparation read and hashed the whole 372 MB installer runtime, then read it again to copy it. Staging now hashes each inventoried file against the manifest as it streams the copy, after a layout and identity check of the installer. A mismatch fails before the file is renamed into the private generation, which is then removed. The first copy failure also stops the remaining workers. Claude-Session: https://claude.ai/code/session_01BgdVQjEFKCM4UR2MTytQgv
- Age reused results with a monotonic clock, so moving the system clock back cannot extend reuse past ten minutes. - Reject inherited object names (constructor, toString, ...) as unexpected runtime resources in every walk. - Hash source bytes during staging only for the trusted installer; pack bases are already fully verified, so packs no longer hash them twice. - Batch folder identity lookups with file lookups, and build verifyRuntime on checkRuntimeLayout. Claude-Session: https://claude.ai/code/session_01BgdVQjEFKCM4UR2MTytQgv
grawish
marked this pull request as ready for review
October 15, 2026 20:18
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by Grawish · project thread
Before: every warm build, every compiler status check and each self-test compile rehashed all ~3,982 runtime files (~372 MB). That accounted for roughly 0.7–0.85 s of a 0.85–1.0 s warm build, and it was the largest main-process CPU context in the long-session V8 diagnostic. First-run preparation also hashed the new copy three or four times and read whole engine binaries (up to 60 MB each, four at a time) into main-process memory.
After: a complete verification is reused while nothing about the runtime has changed. In a synthetic benchmark with the real file count and sizes, a reused check takes 0.13–0.14 s instead of 1.09–1.14 s for a full one. Preparation hashes the new copy once, and it hashes the installer during the copy instead of in a separate full read beforehand. Installer files are streamed through a 1 MiB buffer per copy worker. In the same synthetic setup (self-test stubbed), complete preparation went from 6.1–6.7 s to 4.7–4.8 s.
A result is reused only when all of the following still hold. Otherwise every byte is rehashed.
runtimeReusePolicy.maxAgeMs).Each new process starts with nothing to reuse. A failure is never remembered. A result is stored only when the identity walk after hashing matches the walk before it. Install, repair, resource-pack assembly and the installer-copy check still use the always-complete
verifyRuntime. The bibliography self-test is unchanged.How:
electron/core/runtime.tssplitsverifyRuntimeinto a tree walk and a byte-hash step and addsverifyRuntimeReusing, whichinspectRuntimenow calls. Inruntime-manager.ts, the post-copy check uses the reusing variant so that it seeds the cache, and the staging copy streams through a bounded buffer. The staging copy also hashes every inventoried installer byte, so a damaged installer fails before any file is renamed into place, and the first failure stops the other copy workers. All file and folder flushes are unchanged. A new runtime-manager test covers a same-size damaged installer: nothing is published and a repair works once the installer is restored. Four new tests intests/runtime-verification.test.tscover the following: no re-hashing on a hit, same-size and same-mtime byte changes, rename-replaced, added and symlinked files, expiry, and changes made during hashing. The design and its limits are written up indocs/PERFORMANCE_IMPROVEMENT_PLAN.md.Tested in a Linux container: typecheck,
npm run build, andnpm test(508 pass). The one failure is the existing test that requires macOS sandbox-exec, and it also fails onmainthere. This has not been measured on an Apple silicon Mac or in the packaged app yet. Re-runningscripts/profile-preview.mjswould confirm the warm-build gain before any release claim changes.🤖 Generated with Claude Code
https://claude.ai/code/session_01BgdVQjEFKCM4UR2MTytQgv
Generated by Claude Code
Generated by Claude Code