Repository navigation
perf(compile): reuse rule results on warm and one-edit compiles - #915
Merged
Merged
Conversation
…e unchanged The isolated custom-rule host now records which compiler facts each rule invocation reads through its context. Results are cached per rule and subject and reused only while every recorded fact digest, the rule implementation and import closure, the rules configuration, the installed code identity, and the dialect are unchanged. Rules whose reachable module state changes between invocations, or that touch private view state, are treated as reading every fact. Custom rules no longer serialise the whole compiled project for a cache key: the project is pickled only when a host run is needed, and built-in rules key their project-level identity on request facts instead of walking project files. Refs CHI-443, CHI-444
…ive request Warm compiles re-sent an unchanged 60 MB request to the native engine, which spent about a second re-validating per-model cache entries. The complete response is now memoized under a digest of the serialized request and the installed code identity, so any fact, scope, config or code change re-evaluates through the native per-model cache. Refs CHI-445
Every macro call rebuilt the callable's inspect signature to decide whether to inject the macro context. The decision is now a cached property of the loaded macro, removing about 3,600 signature constructions from a dense 3,000-model compile. Refs CHI-442
Adds 3,000- and 5,000-model dense guards that compile cold, warm, and after a single model edit, then compare the edit with a from-scratch uncached oracle. They assert exact fingerprints, complete warm cache reuse, and that the edit re-evaluates only the edited model's built-in rules while the project-wide custom rule is reused. The dense job timeout grows to cover the extra compiles. Refs CHI-441
…custom-rule results - Record the digest of each project-tree value a rule actually read in the host and refuse to store a result whose filesystem facts changed before the parent recorded the fingerprint. - Key untracked rules on their recorded reads plus every observable fact, so files outside the discovered tree (hidden directories) still invalidate them. - Never cache rules that touch private or unknown fact-view attributes. - Include the thread id in the custom-rule cache temporary file name.
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.
Why
Warm and one-edit compiles re-evaluated every custom rule and the whole built-in rules request even when nothing they depend on had changed, and serialised project facts twice (CHI-441 phase 1: CHI-443, CHI-444, CHI-445, part of CHI-442).
Changes
Verification
make test,make check-ci.