Repository navigation
perf(rules): check custom-rule module state with one shared snapshot - #940
Merged
Merged
Conversation
…per call After every custom-rule call the host re-fingerprinted the module state of every loaded rule code, walking all reachable globals once per code. Each exact fingerprint walk now also traces what it touched: the identity and type of every object it visited, the classes it descended into, and the empty instances whose immutability it checked. One shared snapshot then replays the union of those walks over every code still being monitored and is compared with the snapshot taken when their fingerprints last matched. The snapshot descends only where a traced walk descended and treats any untraced object, any error, or more than the node bound per walk as a reason to fall back, so it never touches or runs code on an object the per-code walks did not. An equal snapshot proves no fingerprint changed; otherwise every remaining code is fingerprinted exactly as before and the trace is rebuilt. Codes sharing a module are fingerprinted once, and codes already stateful are no longer checked. Both walkers share one structural dispatch so they always take the same branch. Classification is unchanged: equality tests compare the monitor with full re-fingerprinting after every call over a corpus of stateful and stateless rule modules, raising and side-effecting attribute hooks the fingerprints never reach, and seeded random mutations, and a CLI test checks split hosts report what one host reports.
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
After every custom-rule call, the rule host re-fingerprinted the module state of every loaded rule code separately, walking all reachable globals each time. The cost grew with calls × enabled codes × state size: on a ~1,400-model project with 9 rules it dominated host CPU once the rules themselves were cheap (CHI-491).
Changes
ModuleStateMonitortakes one shared snapshot over the codes not yet stateful and compares it with the last snapshot at which every code matched its baseline. Any difference, unknown object or error falls back to the exact per-code fingerprint, which still decides classification.module_state_tokenoutput is byte-identical.Verification
make test,make check-ci.