| 12 Feb 2026 |
 ris_ | i should probably undo at least the extensive one | 22:44:08 |
| ris_ | though it's weird 26.xx shipping without flags 25.11 had enabled | 22:44:37 |
| ris_ | i'm sure some packages must be seeing a performance impact | 22:44:54 |
|  Adam joined the room. | 23:15:38 |
| 13 Feb 2026 |
 emily | are there numbers for the expected impact of the two? | 03:27:02 |
| emily |
Extensive mode, which contains all the checks from fast mode and some additional checks for undefined behavior that incur relatively little overhead but aren’t security-critical. Production builds requiring a broader set of checks than fast mode should consider enabling extensive mode. The additional rigour impacts performance more than fast mode: we recommend benchmarking to determine if that is acceptable for your program.
| 03:27:29 |
| emily | doesn't sound like it should be too bad | 03:27:33 |
| emily | specifically marked as suitable for production at least | 03:27:56 |
| emily | fwiw the main user of libc++ in Nixpkgs is macOS and _LIBCPP_HARDENING_MODE_DEFAULT is already 2 (fast) on that platform | 03:29:42 |
| emily | so libcxxhardeningfast is just a nop | 03:30:04 |
|  hoplopf joined the room. | 10:25:27 |
| ris_ | hmmmmmmmmmmmm | 21:51:10 |
| ris_ | well.. open to opinions. i should at least update the documentation to correspond to reality | 21:51:54 |
| emily | I like hardening, but I'm also okay with us matching the platform default here | 22:20:08 |
| emily | not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 | 22:20:30 |
| ris_ | i fear the latter | 22:33:54 |
 Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
not sure if nobody noticing means that the impact is minimal or that nobody is monitoring Nixpkgs package perf 🫣 I sure am monitoring nix perf :) glibcxx assertions absolutely tank inlining in the parser | 23:54:31 |
| emily | I don't think that cleanly maps to libc++ hardening though | 23:55:00 |
| emily | (and probably ~nobody is using Nix with libc++ on Linux) | 23:55:14 |
| Sergei Zimmerman (xokdvium) | I think glibcxx assertions are roughly second level libc++ hardening. At least that’s what meson enables with n_debug | 23:56:14 |
| Sergei Zimmerman (xokdvium) | In my experience the overhead is enough to necessitate disabling hardening for some translation units that are just too hot and aren’t security sensitive | 23:57:38 |
| emily | second level = fast (numeric value 2) or extensive? | 23:58:24 |
| emily | because macOS upstream default is fast so we certainly wouldn't go below that OOTB | 23:58:31 |
| emily | would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway | 23:59:07 |
| emily | (but controlling for version might be hard?) | 23:59:12 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
because macOS upstream default is fast so we certainly wouldn't go below that OOTB As in the llvm toolchain enables that by default? | 23:59:13 |
| 14 Feb 2026 |
| emily | yes:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__config_site
43:#define _LIBCPP_HARDENING_MODE_DEFAULT 2
| 00:00:26 |
| emily | (2 is fast) | 00:00:29 |
| Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
would be interesting to see if 25.05 → 25.11 regresses macOS Nix perf anyway Hm, I guess the only way to tell is to benchmarking :) I could see about how that would affect nix itself. Undefing the flag should be easy enough | 00:05:09 |
| ris_ | i'm going to prepare a PR to switch back to fast | 11:04:39 |
