The storage team reported the following issue:
We recently deployed a build with Azure-Storage-Blobs_12.6.2, but we noticed that there were high CPU usage within the SDK.
After some investigation, we found that this might be caused by: : Unnecessary locking around classic locale · Issue #3030 · microsoft/STL (github.com). We are currently using “set(VCPKG_PLATFORM_TOOLSET v142)” in order to build the SDK, which corresponds to the Visual Studio 2019 platform toolset. A short term mitigation would be for us to try using an older azure-core-cpp version before this change was introduced using vcpkg, but do you all have any recommendations for what the best course of action is?
The problem was introduced in a recent change to modify calls to std::toupper and a number of other functions to include a call to std::locale::classic() to select the classic "C" locale. The problem is that as called out in the linked issue above, there is a scalability problem with this API.
Instead of calling std::locale::classic() in the inner loop, it appears that the value of std::locale::classic() can be safely cached locally thus avoiding the scalability problems.
The storage team reported the following issue:
The problem was introduced in a recent change to modify calls to
std::toupperand a number of other functions to include a call tostd::locale::classic()to select the classic "C" locale. The problem is that as called out in the linked issue above, there is a scalability problem with this API.Instead of calling
std::locale::classic()in the inner loop, it appears that the value of std::locale::classic() can be safely cached locally thus avoiding the scalability problems.