You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Swift: Avoid module-wide indexing when naming imported extensions #22771
SwiftMangler::visitExtensionDecl obtains a discriminator through getExtensionOrFilePrivateValueIndex, which enumerates the imported module's top-level declarations. For Clang-backed extensions, this materializes unrelated declarations merely to construct an internal identity.
A real-AST synthetic fixture with two imported Objective-C categories allocates 34,736 additional AST bytes during mangling with no unrelated C structs, and 279,568 bytes with 200 unrelated structs. The equivalent global-as-member fixture grows from 23,944 to 268,776 bytes. These figures measure work in the mangler, not whole-build savings.
Steps to Reproduce
Define an Objective-C root class and categories in nested Clang submodules, or C globals mapped into Swift members with swift_name.
Add otherwise-unused C structs to the module.
Typecheck Swift references, then name the referenced imported members with SwiftRecursiveMangler while measuring NumASTBytesAllocated before and after mangling.
Expected Behavior
Naming already-referenced imported extensions should not import unrelated declarations from the enclosing SDK/module.
Actual Behavior
AST allocation during mangling scales with unrelated module contents.
A proposed focused correction uses Clang's category USR, and the Swift importer's existing nominal-type/Clang-submodule grouping for global-member extensions. This intentionally changes internal imported-extension TRAP keys; Swift-source/fileprivate indexing and the recursive fallback from #22234 must remain intact. Regression coverage includes nested submodules, late imports, reference reordering and identity uniqueness. No compiler filters, caching workaround or downstream wrapper is proposed.
AI assistance: GitHub Copilot assisted with implementation and validation.
Thanks for your report. Unless I'm misunderstanding something the overhead here seems pretty minimal (measured in KiBs). For this reason, and because we are working on a replacement solution, we will not prioritize fixing this.
@jketema yeah I think you are right. I am doing a comparison right now and will post results on the PR. If marginal, I will close the PR with that info, if substantial I will keep it open, for you to have a second look. But my gut, and current progress shows the same as you, the outcome of the optimization looks to be very little.
And really nice to hear you are working on a replacement solution. Hopefully it will also be a lot faster, as I started this work because our product teams at my workplace experience very slow performance on CodeQL scans on their Swift applications (~20m, where build time is ~7-8m without CodeQL tracing).
Activity
jketema commentedon Oct 7, 2026
Hi @devantler,
Thanks for your report. Unless I'm misunderstanding something the overhead here seems pretty minimal (measured in KiBs). For this reason, and because we are working on a replacement solution, we will not prioritize fixing this.
devantler commentedon Oct 7, 2026
@jketema yeah I think you are right. I am doing a comparison right now and will post results on the PR. If marginal, I will close the PR with that info, if substantial I will keep it open, for you to have a second look. But my gut, and current progress shows the same as you, the outcome of the optimization looks to be very little.
And really nice to hear you are working on a replacement solution. Hopefully it will also be a lot faster, as I started this work because our product teams at my workplace experience very slow performance on CodeQL scans on their Swift applications (~20m, where build time is ~7-8m without CodeQL tracing).
devantler commentedon Oct 7, 2026
@jketema there is some difference. I can provide more details, or do more testing if needed:
#22772 (comment)
devantler commentedon Oct 7, 2026
Closing it. See #22772 (comment).