* libstdc++ has an internal reference to its own address for the SSO. If the moved-from string was referencing its SSO buffer, the moved-to string needs to use its own address. The branch is differentiating the SSO state from a heap-allocated state.
* libc++ string move can be implemented this way, but the branch ends up happening on access to the string. It still needs to discard the old heap allocated buffer, if need-be as well.
As mentioned in that Stack Overflow post, though, things change again with FSRM (Fast Short Rep Mov).
While there are still startup costs, the overhead of calling a function (especially via a PLT) and incurring instruction cache misses is hard to demonstrate in a microbenchmark, while rep movsb encodes more compactly than many flavors of call. In an actual application though, the "slower" but smaller implementation can often win (https://research.google/pubs/pub50338.pdf and https://research.google/pubs/pub48320.pdf)
"Profiling a warehouse-scale computer" (by S. Kanev, et. al.) showed several % of CPU usage allocating and deallocating memory. While a malloc and free does have some data dependencies, the indirect jump (by dynamically linking) is an avoidable cost on the critical path by statically linking.
This is the modern version--based on Abseil--that we use in production for practically every C++ binary. It includes a number of performance optimizations (per-CPU caches, an improved fast/slow path, and a hugepage-aware backed), along with improved telemetry (a low overhead, always-on heap profiler, for example).
gperftools includes a decade+ old copy of TCMalloc and several other things (a signal-based CPU profiler, a heap checker, etc.). The two have diverged significantly.
They're not confidence intervals, but weather.gov's forecasts include a link to the NWS office's forecast discussion (updated every few hours). This can give you a bit of insight into forecaster uncertainty and the variation between models.
To excerpt the most recent (8:14PM EDT) NYC office's discussion:
"As a result, expect most precipitation to be focused mainly during the evening hours. Hi-resolution models have been suggesting that the overnight hours could be mainly if not entirely dry. This is due to 850 hPa warm front lifting to the north by around 6z and a dry slot moving in from the SW (DC/PHI area). For now, have just lowered pops to chance. If trends in the high resolution models hold, pops will need to be lowered further if not removed for the overnight hours with future updates."
* If the "wrong" GPG binary is loaded, the game is likely already up: If an attacker has that degree of control over your machine, they're already on the other side of this airtight hatchway. They can attach to your running programs, read memory contents, and so forth, so compromising the GPG binary isn't necessary.
* Keys are handled by GPG, which normally should mlock key material.
* Part of my plan to switch to handling pages (rather than allowing data to be managed via a std::string) was to be able to use mlock() properly. I'll be adding that soon.
* Since the GPG binary is running as you, it could do Bad Things to the underlying filesystem (or filesystem exported by FUSE), but you do raise a point about closing file descriptors for general cleanliness.
* libstdc++ has an internal reference to its own address for the SSO. If the moved-from string was referencing its SSO buffer, the moved-to string needs to use its own address. The branch is differentiating the SSO state from a heap-allocated state.
* libc++ string move can be implemented this way, but the branch ends up happening on access to the string. It still needs to discard the old heap allocated buffer, if need-be as well.