Super short summary: Using ntohs in code resulted in huge bloat with both gcc and clang. The preprocessor must see it as a function call, ntohs(), to replace it with its built-in equivalent. So using std::transform on something that is normally a macro but has a library fallback will cause your code to slow down considerably (and in my case not be able to keep up with a real-time processing flow).
https://gcc.godbolt.org/z/dM2Ge4 is a MWE (also attached to this gist). As of 4 May 2020, both compilers' trunks with -std=c++17 -Ofast will call the ntohs from an internal library with the "naked" std::transform call. If your compiler supports lambdas, the second iteration works around the issue. If not, the hand-unrolled third version produces the exact same assembly as the second.
This is because if you dig deep enough, you will find in inet/netinet/in.h that ntohs is a macro pointing to __bswap_16. But