`cargo semver-checks` takes much longer after upgrading to version 0.30.0 from 0.24.1

[ysaito1001]

Steps to reproduce the bug with the above code

In smithy-rs (the code generator for AWS SDK for Rust), we run cargo semver-checks as part of CI. As described in this PR, we noticed that the execution time for a GitHub action step for semver-checks increased from 15 minutes to nearly 4 hours after we had upgraded the semver-checks version from 0.24.1 to 0.30.0.

We run semver-checks against 49 crates in CI, and it looks like only a few of them cause a long tail of the total execution time. One of them is aws-sdk-ec2 (there could be offending crates but this happened to be the first I noticed).

Here are reproduction steps:

1. Clone the aws-sdk-rust repository and run cd aws-sdk-rust/sdk.
2. Install cargo semver-checks version 0.24.1

cargo install cargo-semver-checks --locked --version 0.24.1

3. Run

cargo semver-checks check-release --baseline-rev main --manifest-path ec2/Cargo.toml -v -p aws-sdk-ec2 --all-features --release-type minor

This is pretty much how our CI script runs semver-checks.

4. Install cargo semver-checks version 0.30.0

cargo install cargo-semver-checks --locked --version 0.30.0

5. Run the same command as step 3

---

FYI, we are not blocked by this, since we can continue using 0.24.1 in our CI for now.

Actual Behaviour

With version 0.24.1, step 3 takes around 14 seconds:

   Completed [  13.446s] 45 checks; 45 passed, 6 unnecessary

With version 0.30.0, step 5 does not return a result (at least not before I give and hit Ctrl+C):

    Starting 61 checks, 6 unnecessary on 10 threads
(stuck at this point)

Expected Behaviour

I expect step 5 (with version 0.30.0) to finish in a similar amount of time as version 0.24.1.

Generated System Information

Software version

cargo-semver-checks 0.30.0

Operating system

macOS 13.6.6 (Darwin 22.6.0)

Command-line

/Users/awsaito/.cargo/bin/cargo-semver-checks semver-checks --bugreport 

cargo version

> cargo -V 
cargo 1.75.0 (1d8b05cdd 2023-11-20)

Compile time information

• Profile: release
• Target triple: aarch64-apple-darwin
• Family: unix
• OS: macos
• Architecture: aarch64
• Pointer width: 64
• Endian: little
• CPU features: aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,fp16,frintts,jsconv,lor,lse,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,vh
• Host: aarch64-apple-darwin

Build Configuration

No response

Additional Context

No response

[Predrag Gruevski]

Thanks for the report, and sorry for the inconvenience. It sounds like some of the newer lints escaped the optimizations I implemented the last time around.

I'll try to look into this when I get the chance.

[Predrag Gruevski]

v0.32.0 which was released yesterday should do a bit better on this.

Unfortunately, it only contains a fix for the immediate cause of the slowdown this time around — the problem is likely to come back again and again as new lints are added. Since the AWS SDK crates are so large, when this problem happens again, it will hit your use cases the hardest by far.

The best answer here is to sign a support contract, where I commit to an SLA for triaging and resolving (and when possible, entirely preventing) these kinds of issues in exchange for a recurring payment. This is different than OSS sponsorship, since the OSS license terms do not guarantee any performance or fitness of the software, nor triage timelines for open issues. A support contract would guarantee those things, and the funding I'd get would let me carve out more time to work on cargo-semver-checks issues and functionality important to your use cases.

Would you be able to put me in touch with your manager or director so we could discuss setting up such an arrangement? I'd really appreciate it! My contact info is in the Cargo.toml file: https://github.com/obi1kenobi/cargo-semver-checks/blob/main/Cargo.toml#L5