Can the build script be removed or reduced?

[hanna-kruppe]

I was wondering what the build script is needed for, because any build script invites some scrutiny and makes build times slightly worse (especially if the library otherwise has no dependencies!). From a quick look, everything done in the build script seems replaceable:

• Rust version check for AArch64 SIMD intrinsics which were stabilized after MSRV (1.47 vs. 1.59). I didn't find anything written down about how MSRV is determined and when it can be increased, but even the very conservative policy of "whatever a year-old Debian stable supports" would allow 1.63 nowadays.
• Checking and setting a bunch of ad-hoc cfgs to control whether SIMD is used at all and how it's detected. I believe all of these could be just spelled out in the source code with normal #[cfg(...)] expressions, though this may be somewhat more complex and will lose the warnings that the build script emits. But maybe this is a good chance to reconsider which of these knobs are actually needed: I find it hard to imagine someone relying on them for anything but one-off tests and tolerating the resulting warnings on every build.
• Something about cfg(target_feature=....) being unstable, which was true at the time that comment was written but hasn't been true since Rust 1.27.
• Printing some warnings if SIMD usage is disable due to lack of std feature or running under Miri. These don't have any non-build-script equivalent, but if they'd be the only remaining reason to have a build script, then they don't seem important to keep around in my view. But even if they're left in, the build script would be much smaller and simpler than today.

I might try my hand on some of these changes (no promises though!) but of course that doesn't make any sense if you'd rather keep the build script's functionality as-is.

[seanmonstar]

Probably! It was initially added to support new features without forcing a new compiler. The biggest addition was the SIMD support. But that was years ago. I have no problem increasing the MSRV for a specific improvement, like removing the build script.

Of all the things, I think they only valuable thing is being able to explicitly disable SIMD for testing purposes. But a mechanism to do that (that's still fast) which doesn't use a build script is a fine upgrade. (Just not something I'm focused on at the moment.)

[hanna-kruppe]

Of all the things, I think they only valuable thing is being able to explicitly disable SIMD for testing purposes. But a mechanism to do that (that's still fast) which doesn't use a build script is a fine upgrade. (Just not something I'm focused on at the moment.)

I think you could even keep the same mechanism (passing --cfg flags), just use the relevant cfgs directly in the source code attributes instead of factoring them into the build script logic that sets cfg(httparse_simd) and others. It adds yet another thing to some already-complicated #[cfg(...)] but perhaps there's some refactoring waiting to be discovered. Do you want to keep both "disable SIMD entirely" and "disable compiletime detection" or only the former?

[seanmonstar]

Oh right, compile time detection... That was a thing, along with the custom runtime static thing we have, because the runtime detection in libstd would not inline, and this was slower than an atomic load.

I highly suspect that has been fixed in libstd for a long time, and we could remove all of that. But I haven't measured...

[hanna-kruppe]

Code gen does look good in a simple example: https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=d4061fbe38060120707ddba3991d26a1 (edit: changed link to a more comprehensive example)

The branch to initialize on first access should be the same or better as httparse’s custom equivalent. The std version keeps the first-access path #[cold] and outlined, that’s probably better codegen than what httparse does currently (PGO might equalize it). Checking two features does the whole dance twice, but if it matters then checking AVX2 first will fix that — nobody who’s looking for good performance is still using a pre-AVX2 x86 CPU. (Not sure if there’s any SSE4.2 code paths that are useful even when AVX2 is available, but those don’t need to check AVX2 so it’s still only a single check for those.)