windows: Make readLinkW APIs output WTF-16, reduce stack usage of callers #25539
+247
−79
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
The reasoning in the comment deleted by this commit no longer applies, since that same benefit can be obtained by using OpenFile with `.filter = .any`. Also removes a stray debug.print
…lers - Deprecates the following with a `2` suffixed replacement (in the future, the `2` suffixed functions will be renamed over top of the deprecated functions): + `std.fs.Dir.readLinkW` -> `readLinkW2` + `std.os.windows.ReadLink` -> `ReadLink2` + `std.os.windows.ntToWin32Namespace` -> `ntToWin32Namespace2` + `std.posix.readlinkW` -> `readlinkW2` + `std.posix.readlinkatW` -> `readlinkatW2` Each of the deprecated functions (except `ntToWin32Namespace`) took WTF-16 as input and would output WTF-8, which makes optimal buffer re-use difficult at callsites and could force unnecessary WTF-16 <-> WTF-8 conversion during an intermediate step. The new functions output WTF-16, and also allow for the path and the output to re-use the same buffer (i.e. in-place modification), which can reduce the stack usage at callsites. For example, all of `std.fs.Dir.readLink`/`readLinkZ`/`std.posix.readlink`/`readlinkZ`/`readlinkat`/`readlinkatZ` have had their stack usage reduced by one PathSpace struct (64 KiB) when targeting Windows. The new `ntToWin32Namespace2` takes an output buffer and returns a slice from that instead of returning a PathSpace, which is necessary to make the above possible.
squeek502
force-pushed
the
windows-readlinkw
branch
from
ff7e198 to
147accd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Something of a follow-up to #23657, and in particular #23657 (comment) which outlines pretty much exactly the changes made here. Contributes to #23643
2suffixed replacement (in the future, the2suffixed functions will be renamed over top of the deprecated functions):std.fs.Dir.readLinkW->readLinkW2std.os.windows.ReadLink->ReadLink2std.os.windows.ntToWin32Namespace->ntToWin32Namespace2std.posix.readlinkW->readlinkW2std.posix.readlinkatW->readlinkatW2Each of the deprecated functions (except
ntToWin32Namespace) took WTF-16 as input and would output WTF-8, which makes optimal buffer re-use difficult at callsites and could force unnecessary WTF-16 <-> WTF-8 conversion during an intermediate step.The new functions output WTF-16, and also allow for the path and the output to re-use the same buffer (i.e. in-place modification), which can reduce the stack usage at callsites. For example, all of
std.fs.Dir.readLink/readLinkZ/std.posix.readlink/readlinkZ/readlinkat/readlinkatZhave had their stack usage reduced by one PathSpace struct (64 KiB) when targeting Windows.The new
ntToWin32Namespace2takes an output buffer and returns a slice from that instead of returning a PathSpace, which is necessary to make the above possible.