* 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.
Since Haswell indirect jumps have negligible additional cost. See, e.g., "Branch Prediction and the Performance of Interpreters - Don't Trust Folklore", https://hal.inria.fr/hal-01100647
Perhaps Spectre mitigations have changed things, but we're still talking about a fraction of a fraction. As others have said, the best way to improve malloc performance is to not use malloc. Second best would be avoid allocations in critical sections so the allocator doesn't trash your CPU's prediction buffers.
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."
* 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.