The issue is that __libcpp_locale_guard makes some slow calls to setlocale().
This change avoids using __libcpp_locale_guard in snprintf_l().
Details
Diff Detail
- Repository
- rCXX libc++
Event Timeline
include/__locale | ||
---|---|---|
67 | I'm not really familiar with locales, but if I'm reading MSDN correctly, wouldn't you need a call with a NULL locale argument to get the value of all categories? I'm not sure how you'd then use that to restore the categories though. Also, "Global or thread local storage is used for the string returned by setlocale. Later calls to setlocale overwrite the string, which invalidates string pointers returned by earlier calls." Shouldn't we be copying the return value instead of just storing a pointer? (This is already potentially a problem with the existing code, unless I'm misunderstanding things.) |
include/__locale | ||
---|---|---|
67 | Yeah, you're right. How was this ever working? haha I've reverted the __locale changes. I'll try to write a fix in a separate CL. For now, the change in locale_win32.cpp is all that's needed to fix Chromium's perf issues after switching to libc++ on Windows. |
LGTM, though you'll wanna update the commit message.
src/support/win32/locale_win32.cpp | ||
---|---|---|
93 | Any reason for preferring this over _vsnprintf_l? I think they'll end up being basically equivalent here, except _vsnprintf_l is more in line with the else branch. |
Unrelated, but out of curiosity: I believe libc++ is set up to require building against the Windows 10 SDK and the Universal CRT right now. For older Windows versions, does Chrome require the Universal CRT to be installed?
Done.
No, I believe we statically link the CRT
src/support/win32/locale_win32.cpp | ||
---|---|---|
93 | I just found out about _vsprintf_s_l first. Changed! |
The CL said "approved, ready to land". Clearly I'm not very good at this. Please go ahead and revert and/or revoke my committer permissions. Whatever you gotta do.
@mclow.lists – this is a small localized change specific to libc++'s Windows support. The only libc++ specific thing here is the use of the _LIBCPP_MSVCRT conditionals, but they're consistent with the rest of this file (and with the general intent to support non-msvcrt runtimes on Windows). I've reviewed and contributed a bunch of libc++ Windows support, so I considered myself to be a qualified reviewer for this change, although for this particular change I think anyone sufficiently familiar with msvcrt would be able to review it.
I'm happy to not accept diffs in libc++ directly anymore and instead comment something like "LGTM, but wait for one of @mclow.lists, @EricWF, or @ldionne to review as well", but that seems like a pretty heavy handed policy for changes like this. I'm also curious if you have any specific issues with this diff, or if it's just a general principle.
https://libcxx.llvm.org has a section saying "Get it and get involved! First please review our Developer's Policy." that links to https://llvm.org/docs/DeveloperPolicy.html That page has a section https://llvm.org/docs/DeveloperPolicy.html#code-reviews that says "Code can be reviewed either before it is committed or after. We expect major changes to be reviewed before being committed, but smaller changes (or changes where the developer owns the component) can be reviewed after commit.". If libcxx's review policy is different from what it's documented as being, consider updating the documentation.
(The next section, https://llvm.org/docs/DeveloperPolicy.html#code-owners , talks about codifying the code owners policy a bit; libcxx should probably have a CODE_OWNERS.txt file like other llvm projects.)
I'm not really familiar with locales, but if I'm reading MSDN correctly, wouldn't you need a call with a NULL locale argument to get the value of all categories? I'm not sure how you'd then use that to restore the categories though.
Also, "Global or thread local storage is used for the string returned by setlocale. Later calls to setlocale overwrite the string, which invalidates string pointers returned by earlier calls." Shouldn't we be copying the return value instead of just storing a pointer? (This is already potentially a problem with the existing code, unless I'm misunderstanding things.)