[Minor perf] Avoid unnecessary allocations

[blyxyas]

Commits:

1. Reserve store.late_passes with 320 and store.early_passes with 64, this leaves us some leeway for adding new passes. Note that there are not as many passes are there lints.
2. Add [env] with some MALLOC_CONF for mainly for faster testing, but to also optimize in profiling.

This PR makes it so we avoid unnecessary reallocations, oh and we now use MALLOC_CONF for some heap-allocation optimization (I tested manually every config flag and came to this conclusion, see jemalloc/TUNING.md). I'm not sure if this would impact on rustup-distributed binaries, but I'm also taking some measures to make sure that rustup-distributed Clippy binaries (and the Rust compiler overall)) use all of Jemalloc

The performance gains vary depending on factors outside of the users control, but in wasmi (my favourite crate to benchmark due to the 66K LOC) it varies between 100ms to 400ms. Overall a solid optimization.

How to test:

There are two ways to benchmark, either with cargo lintcheck --perf in the checkout and in master, then perf diff perf.data perf.data.0, or with RUSTFLAGS="-Zself-profile" cargo dev lint <my_crate>, and measureme. Choose whichever one is most comfortable.

changelog: Minor allocation performance improvements.

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Jarcho]

r? @flip1995

I don't know how the malloc config interacts with builds in the rustc repo.

[flip1995]

I have no idea who to ask about the effects of using MALLOC_CONF 🤷 t-bootstrap, t-compiler, t-infra, t-release? I would think t-bootstrap? Or maybe t-compiler/performance? I'd like to get some input from people closer to the compiler before merging this.

[Kobzol]

So Clippy doesn't use jemalloc at the moment, so for the MALLOC_CONF, we should first actually switch to it 😆 The preallocation makes sense, I suppose, and could be landed separately.

[flip1995]

@blyxyas Should we remove the MALLOC_CONF from this PR, merge the pre-allocation and revisit the MALLOC_CONF once/if we switched to jemalloc?

[Kobzol]

Oh, actually I didn't realize that the MALLOC_CONF thing is configured for Cargo (I thought it's configured for Clippy invocations themselves). This means that the environment variable might speed up the compilation of Clippy itself, since the host rustc probably does use jemalloc. So that makes sense.

[blyxyas]

Yeah, the reserves are only to avoid some reallocation we do on every Clippy run, it was just something nice to have. This PR is mainly to speed up compiling Clippy itself for cargo uitest and such.

[flip1995]

Ah, I see. I misunderstood this then. Let me try on the next sync, if this affects building Clippy in the Rust repo in any way, and if it doesn't, merge this as-is.

[flip1995]

Ideally add a comment here explaining that this is for building Clippy a bit faster