Replace almost all public static lets with computed vars #3229
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
Motivation: Public static lets can serve a bunch of roles, but one of them is to store simple constants: integers, and other trivial types, for example. This is a nice pattern and for internal and private static lets it works well, but for public ones it produces some inefficient code. In particular, it has two downsides. First, it allocates storage for that value. We don't actually need to allocate a few hundred extra megabytes for the various integers we want to store. Secondly, it forces calling code to access the address and call the dispatch_once code in order to get hold of the value. For trivial types we don't need that cost: they can just know what the value is directly. Inlinable computed vars avoid all of these costs: they have no size overhead for storage, and they are visible to all clients so their values can be directly assembled. While I'm here, I added a bunch of other inlinable annotations for a few trivial data types I stumbled onto. Modifications: - Added loads of inlinables. Like, loads. - Swapped many static lets to static vars. Result: Better codegen, smaller memory footprints, more attributes.
glbrntt
approved these changes
May 2, 2025
glbrntt
added
🔨 semver/patch
This was referenced May 30, 2025
agamdua
added a commit
to apple/swift-ntp
that referenced
this pull request
Jun 12, 2025
Converts static let properties from stored to computed properties ### Motivation: Replicating pattern adopted in apple/swift-nio#3229 ### Modifications: convert static let declarations to computed properties, applied annotations for inline usage ### Result: No operational change, but more efficient for memory usage --------- Co-authored-by: Agam Dua <[email protected]>
fabianfett
reviewed
Jul 8, 2025
|
|
||
| /// A hex dump analog to `plain` format but without whitespaces. | ||
| public static let compact = Self(.compact(maxBytes: nil)) | ||
| public static var compact: HexDumpFormat { Self(.compact(maxBytes: nil)) } |
There was a problem hiding this comment.
@Lukasa the above did get an @inlinable, which makes sense based on the discussion we had last week. This one didn't. Is this an oversight?
There was a problem hiding this comment.
Almost certainly, yes.
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:
Public static lets can serve a bunch of roles, but one of them is to store simple constants: integers, and other trivial types, for example. This is a nice pattern and for internal and private static lets it works well, but for public ones it produces some inefficient code.
In particular, it has two downsides. First, it allocates storage for that value. We don't actually need to allocate a few hundred extra megabytes for the various integers we want to store.
Secondly, it forces calling code to access the address and call the dispatch_once code in order to get hold of the value. For trivial types we don't need that cost: they can just know what the value is directly.
Inlinable computed vars avoid all of these costs: they have no size overhead for storage, and they are visible to all clients so their values can be directly assembled.
While I'm here, I added a bunch of other inlinable annotations for a few trivial data types I stumbled onto.
Modifications:
Result:
Better codegen, smaller memory footprints, more attributes.