-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[DO NOT MERGE] More experiments with UnsafeBufferPointer.init #35075
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Every other Unsafe(Mutable)BufferPointer precondition in this file is debug-mode only. This information is already part of the documentation for this function, and it's really hard to get rid of these branches and traps otherwise.
…ckedBounds:) Unchecked APIs must still perform checks in debug builds to ensure that invariants aren’t violated. (I.e., these aren’t a license to perform invalid operations — they just let us get rid of the checks when we know for sure they are unnecessary.)
`Slice` does not technically guarantee that its indices are valid in its base, so these initializers accidentally allowed the creation of obviously out-of-bounds buffers.
This eliminates a couple of _debugPreconditions which seem to change inlining enough to interfere with some benchmarks.
When the stdlib says not to check, it’s a good idea to actually not have any checking, so that we leave existing code paths unchanged. (And because we do trust that the stdlib is responsible about such things.)
…nversions The UnboundRange → Range conversion path is complicated and it involves at least one unnecessary _precondition check for startIndex ..< endIndex.
|
@swift-ci benchmark |
Performance: -O
Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone
Code size: -swiftlibsHow to read the dataThe tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.If you see any unexpected regressions, you should consider fixing the Noise: Sometimes the performance results (not code size!) contain false Hardware Overview |
|
Nah, this is slightly worse than the original. |
This is a spinoff of #34961 that reintroduces a
_preconditionforcount >= 0; that particular static invariant may have a beneficial effect on overall performance.