Use proper String unsafeUninitializedCapacity initializer. #263
Conversation
This file contains 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
Motivation: A while ago we shimmed out the String unsafeUninitializedCapacity initializer because while it was on the road to being implemented, it hadn't actually been implemented. Now it has! On Apple platforms, the initializer is guarded behind an availability guard. We need to add that guard here. This means we need to keep hold of the backport for a good long time, until we raise our minimum Apple platform support to a new enough version. Happily, Linux on 5.3 should just see a net win here. Modifications: - Updated to enable us to use the proper initializer. Result: Fewer allocations when screwing around with HPACK.
Lukasa
force-pushed
the
cb-remove-string-override
branch
from
5aaf12f to
9f4bb29
Compare
Lukasa
added a commit
that referenced
this pull request
Dec 3, 2020
Motivation: In #263 we took advantage of the addition of the unsafeUninitializedCapacity:initializingWith constructor on String, added in the latest Swift SDKs and Swift versions. Unfortunately, there were a few Xcode releases that shipped with Swift 5.3 but _without_ the macOS 11 SDK. These releases therefore had a 5.3 compiler, but no access to the macOS 11 SDK where the constructor is defined. This means this change regressed builds on those platforms. Modifications: Removed access to the fast-path initializer on Apple platforms in 5.3. The initializer is present and will continue to work on non-Apple platforms. Apple platforms will get access to that initializer from 5.4 onwards. Result: Fewer build issues for users using Xcode 12.0 and 12.1.
Merged
Davidde94
pushed a commit
that referenced
this pull request
Dec 3, 2020
Motivation: In #263 we took advantage of the addition of the unsafeUninitializedCapacity:initializingWith constructor on String, added in the latest Swift SDKs and Swift versions. Unfortunately, there were a few Xcode releases that shipped with Swift 5.3 but _without_ the macOS 11 SDK. These releases therefore had a 5.3 compiler, but no access to the macOS 11 SDK where the constructor is defined. This means this change regressed builds on those platforms. Modifications: Removed access to the fast-path initializer on Apple platforms in 5.3. The initializer is present and will continue to work on non-Apple platforms. Apple platforms will get access to that initializer from 5.4 onwards. Result: Fewer build issues for users using Xcode 12.0 and 12.1.
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.
Motivation:
A while ago we shimmed out the String unsafeUninitializedCapacity
initializer because while it was on the road to being implemented, it
hadn't actually been implemented. Now it has!
On Apple platforms, the initializer is guarded behind an availability
guard. We need to add that guard here. This means we need to keep hold
of the backport for a good long time, until we raise our minimum Apple
platform support to a new enough version. Happily, Linux on 5.3 should
just see a net win here.
Modifications:
Result:
Fewer allocations when screwing around with HPACK. Fractionally faster performance in general (~0.2%).