Repository navigation
perf(lowering): index optimization directives per file - #606
Merged
Merged
Conversation
optimization_state_at scanned every recorded #! directive event for each lowered value, making the cost values x directives (about 81,927 queries against 652 records on Bastion). Build a per-file index of directive positions and optimization states once per lowering and answer each query with a partition_point binary search over that file's events. Semantics are unchanged: the index reproduces the scan's ordering (last directive at or before the query position in the same file wins), including files with no directive, positions before the first directive, included files, and spans without file information. The emitted Bastion Workshop output is byte-identical (sha256 7f53ffa8...) and the previous scan is retained as the test-only oracle optimization_state_scan; new tests diff it against the index over every span lowered by the corpus, a synthetic edge-case fixture, and the full Bastion project (OPY_BASTION_PROJECT). Measured on the lpp/compile-equivalent harness (release, 14+ interleaved warm runs): backend median 189.3ms -> 164.2ms, total median 301.4ms -> 280.4ms on a machine under unrelated load. The ~25ms backend gain is slightly below the issue's 30-40ms profile estimate. Fixes #596
Merged
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
2 participants
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.
Fixes #596
optimization_state_atscanned every#!directive record for each lowered value. It now looks up a per-file index built once perLowering(a map from file to the directive positions and states, queried with a binary search for the last directive at or before the position). The previous scan is kept in test code only, as the oracle.Measured on the Bastion project (211 files, zh-CN;
lpp/compile-equivalent harness, release, 14+ interleaved warm runs, medians):The gain, about 21–25 ms, is lower than the Issue's 30–40 ms estimate. The estimate came from a sampling profile; a timer around the function had reported only about 7 ms. The measurements were taken while the machine carried unrelated load, so treat the numbers as approximate.
Equivalence: the emitted Bastion output is byte-identical before and after (sha256
7f53ffa8…). Tests compare the index with the old scan over every span lowered by the corpus, a synthetic edge-case fixture (no span, before the first directive, exactly at a directive, one column before, included files, unknown file ids), and the full Bastion project whenOPY_BASTION_PROJECTis set (81,927 queries, no disagreement). The new corpus fixturesynthetic/optimization-state-edgecarries anoracle.jsonproduced by the pinned upstream OverPy 9.7.17, not by this compiler.cargo fmt --check,cargo clippy --workspace --all-targets -D warningsandcargo test --workspacepass with no changed expectations.