Repository navigation
perf(engine): look for an import's uses in its own file only - #193
Merged
Merged
Conversation
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.
Summary
Before and after a save rewrites a page, the builder asks which named imports the page file uses, so it can prune the ones the rewrite orphaned. It asked once per import with a project-wide find-all-references. That search reads every other file and builds display text for each definition, then keeps only the hits in the page file.
The highlights are those of the local binding: the alias, else the name. That is what a use in the file refers to.
Evidence
Evidence level: benchmark (micro and engine operations).
referencedImportNameson the Board page (24 named imports), after an edit, 5 runs:Both give the same names, including an aliased import that is used (
Get as Fetch) and one that is not (Post as Unused).A save (
SetPageBlocks), sides interleaved:On main with one page the gain hides inside the whole-program typecheck, which then pays the program rebuild the search used to pay. The typecheck fix removes that.
Cumulative impact: the search runs twice per save, so the cost grows with the number of pages in the app. That is about 0.3 s per save at 1 page and seconds at 100 pages.
The engine specs (
test:unit) pass: 523 passing.Verification
pnpm run checkspasses. Main failssync:checkon a stale compat row inpackages/dms-builder/README.md(interface-dms-builder 0.4.0, published 0.4.1), so a separate commit syncs it. It is the same line build(deps): move to @antelopejs/tooling-configs 0.5.0 #190 carries, byte for byte, so whichever of the two lands second has an empty or trivial conflict there.smoke,blocks(3),pages(3) andresources(4) journeys pass. Dashboard save, Save click to the server's answer, 15 saves per side: 2325 ms (2010–3792) on main, 630 ms (440–1102) with the three PRs.formal-page-save: the same output on main and on this branch. The only finding is the recorded F2 (Moving a page with an unsaved draft lets the next Save overwrite an outside change without the stale banner #163), which none of these lines touch. The gate flags the covered code's emit as changed.Merge Danger
Door: two-way.
Blast Radius: import pruning on save.
Two theoretical forms differ, and the reviews found neither in a page the builder writes. The first is an aliased import whose export does not resolve: it is now counted as used. The typecheck refuses that save either way. The second is the same export bound twice through different names: the unused one is now kept, as
pruneUnusedImportsintends.