User/dmachaj/slim source location #1379
Merged
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.
Fixes: #1337
Why is this change being made?
This change is being made because a lot of projects are having to disable
std::source_location
usage because the binary size impact is too large or because they are overly concerned about information leakage with fully-annotated function names being in the binary. We have see binaries spike in size by 50% (see https://devblogs.microsoft.com/performance-diagnostics/deep-dive-analysis-why-did-this-dll-increase-in-file-size-by-50/ for an example).The biggest contributor here is
std::source_location::function_name
. Those have the largest number of unique strings and they are often the largest strings too. This is especially bad when the function is templated because each expansion gets a unique name in the binary and they cannot fold. Sadly it is not possible to selectively disable this aspect without disabling all of it.Function name is also less critical than file name and line number. With file/line information the function name can be figured out from the source code.
This set of changes are being made to try and get the best bang for our binary-size buck.
Briefly summarize what changed
A new
winrt::details::slim_source_location
struct has been created to be highly similar tostd::source_location
while skipping function_name. This is powered using__builtin_LINE
and__builtin_FILE
so it should be the same underlying implementation provided by the compiler. It has the same fields so it should be a drop-in replacement.Instead of a wholesale replacement the behavior here now depends on whether
_DEBUG
is defined. The theory is that debug builds are less sensitive to binary size so including function names is helpful and the downside doesn't matter. Non-debug (aka release) builds use the new slim_source_location struct instead.I encountered an order-of-concatenation problem between
base_types.h
andbase_macros.h
so I had to include this struct in base_macros. The type must be fully defined before it can be used by the macros. The types header comes after the macros so the order of operations was wrong. This is not ideal but it compiles.I also tweaked the ODR violation check to have a different value between these source location types. Linking translation units with different understandings of source location will trigger a build break.
How was this change tested?
build_test_all.cmd
locally.I also swapped out the cppwinrt.exe used by our product code and rebuilt the project as both debug and release. (The latest stable release was 6 months ago and has had breaking changes so the switchover was annoyingly nontrivial.). When debugging I can see that the
originate
method hasstd::source_location
in debug builds andwinrt::impl::slim_source_location
in release builds. The function_name pointer is null in release builds. The same is true of the WIL logging callback that is hit by originate.I used SizeBench to compare release builds before and after this change. The difference is tiny (2KB). Most files already had strings in the binary thanks to WIL logging. The increase is from cppwinrt generated headers having origination information, which is expected. The small code size increase is worth it for the improved debuggability, in my opinion.