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`](https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=inet/netinet/in.h;hb=HEAD) that `ntohs` is a macro pointing to `__bswap_16`. But without `()`, your preprocessor doesn't know this, so it has to use the library fallback.