[6.0] Cherry-pick a couple of compile-time performance optimizations #76151
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
SourceFile::collectLinkLibraries() did not depend on the source file, so let's move this logic up into ModuleDecl::collectLinkLibraries().
slavapestov
force-pushed
the
compiler-perf-fixes-6.0
branch
from
8676d58 to
a95040c
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
hborla
approved these changes
Aug 29, 2024
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.
6.0 cherry-pick of #75210 and #75164
Description: Profiling revealed a couple of hot spots where we were needlessly iterating over all source files in the main module.
Scope of the issue: Long compile times with projects having a large number of source files.
Origination: The bottleneck in isImportedAsWeakLinked() was introduced in Swift 5.8. The bottleneck in collectLinkLibraries() was introduced in Swift 4.2 or even earlier.
Risk: Low.
Tested: Existing tests passed, and profiling showed the methods in question no longer contribute to compile time.
Reviewed by: @hborla