Skip to content

Applying manual_clamp lint results in slower code #14959

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Shnatsel opened this issue Jun 2, 2025 · 2 comments
Open

Applying manual_clamp lint results in slower code #14959

Shnatsel opened this issue Jun 2, 2025 · 2 comments
Labels
S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work

Comments

@Shnatsel
Copy link
Member

Shnatsel commented Jun 2, 2025

Description

The manual_clamp lint nags me to replace .max(0).min(255) with .clamp(0,255) in image-webp crate, but doing that results in significantly slower code.

You can find the full details and the assembly comparison in the issue I opened on the rustc repo: rust-lang/rust#141915

The root cause of the slowdown is still being investigated.

We've put an #[allow] on the affected piece of code in image-web, but it would be nice to disable this lint by default so it wouldn't cause any further performance regressions across the ecosystem.

Version

I've reproduced the regression on rustc 1.75, 1.82 and 1.87

Additional Labels

No response

@samueltardieu
Copy link
Contributor

I suggest we wait a bit until rust-lang/rust#141915 concludes that this cannot be fixed before allowing the lint by default. Allowing it would not solve the problem retroactively, and it might be fixed soon in the compiler now that the issue is known.

@rustbot label +S-blocked

@rustbot rustbot added the S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work label Jun 2, 2025
@Shnatsel
Copy link
Member Author

Shnatsel commented Jun 2, 2025

Turns out the issue has been known for a year already: rust-lang/rust#125738
Despite that, a fix has not materialized.

The same argument was made on the Clippy side a year ago when this issue was initially discovered: #12826

Given that it's been a year already and there is no fix in sight, but Clippy has been actively making people's code slower through that entire year. Sadly disabling the lint by default will not undo the damage already done, but perhaps it's time to at least stop slowing down new code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work
Projects
None yet
Development

No branches or pull requests

3 participants