Optimize MBE (macro by example) performance

[edwin0cheng]

Recently (#7513) we implemented a new NFA based expander for MBE which is quite slow compared to the old one (based on recursive descent). It would be nice if someone could optimize it to run as fast as possible.

Benchmark

We already have a benchmark for it, to run the benchmark :

$ RUN_SLOW_TESTS=1 cargo test --release --package mbe -- benchmark::benchmark_expand_macro_rules --nocapture

Output should be something like:

running 1 test
mbe expand macro rules: 2.21s, 8464minstr
test benchmark::benchmark_expand_macro_rules ... ok

Source

The corresponding source code of mbe expander is at :

https://github.com/rust-analyzer/rust-analyzer/blob/3b507aa90fca9618ddbe0667e245ef4766aa96b5/crates/mbe/src/expander/matcher.rs#L148-L151

And we have a bunch of compliance tests related to mbe, to run these test :

$  cargo test --package mbe -- --nocapture

Tips

By default, RA turn off the debug information in Cargo.toml :

https://github.com/rust-analyzer/rust-analyzer/blob/3b507aa90fca9618ddbe0667e245ef4766aa96b5/Cargo.toml#L18-L20

You may need to set it to debug = 2
And here is how I run perf in linux:

$ RUN_SLOW_TESTS=1 perf record --call-graph dwarf  cargo test --release --package mbe -- benchmark::benchmark_expand_macro_rules --nocapture
$ perf report --call-graph

[EDIT: added --release flag]

[edwin0cheng]

CC #5549

[jonas-schievink]

It's probably better to run the benchmark with --release, otherwise it doesn't get optimized and you'll optimize for the wrong thing.

[edwin0cheng]

Good point ! Edited for --release

[dzmitry-lahoda]

if this is root cause of #7934 , than it is on linux also, and really slow on diesel compilation (diesel is very very meta template heavy)

[flodiebold]

See also #4186.

[TimoFreiberg]

For me, the benchmark showed improvements when replacing most of the SmallVecs in match_loop and mach_loop_inner with Vecs. I don't know whether my local benchmarks are meaningful though...
Do you want me to create a PR for this? master...TimoFreiberg:7857-benchmark

For the benefit of other readers, here's a flamegraph from my machine.
It looks like cloning the MatchState is the most expensive operation...

[edwin0cheng]

For the benefit of other readers, here's a flamegraph from my machine.
It looks like cloning the MatchState is the most expensive operation...

Yeah, and specially cloning for Bindings , I implemented #7994 for that, but in general it still needed to improve a lot.

[novacrazy]

What is the status of this? I've seen a couple other issues closed and redirecting here, so I'll just say this here.

I have a macro for a quick SQL DSL using embedded Rust syntax and data types, generated from a build-script with around 900 rules, and rust-analyzer absolutely chokes on it. Causes the CPU to spin for multiple minutes, on a single thread and over 10 minutes sometimes, and pushes CPU temperature high enough that I repasted my CPU because it was so concerning. It effectively disables RA for the entire function that macro is used within, at least for those minutes. rustc seems to have no issues compiling it.

Furthermore, after it eventually finishes, RA only recognizes Rust identifiers (with on-hover information) used for about 128 tokens (not exactly measured) into the macro, the rest are left unknown as generic syntax. The macro also defines a datatype which is returned indirectly though another struct's type-parameters and through a closure's return value, deduced via type-inference. RA cannot recognize methods that exist on this type, but does know the name of it and that it implements Deref. Derefed methods do autocomplete, just not methods implemented directly on it from within the macro.

If requested, I could provide a minimal crate using this macro as I do in my real project.