Really slow generation for very large (simple) generated code

[illicitonion]

I just investigated a performance bug in a simple proc macro: illicitonion/num_enum#13

It generates a simple function which declares 7000 consts, and a match with 7000 branches.

If I hand-code the generated code as a string, cargo expand takes 6 seconds.
If I use proc-quote, cargo expand takes 94 seconds.
The only difference is how the TokenStream is generated.

There's a repro here: https://github.com/illicitonion/num_enum_regression_13 - the Cargo.toml has two options for where to get the num_enum dep switching between the implementations. This is the pull request switching from proc-quote to raw String generation: illicitonion/num_enum#14

This is the code that gets generated: https://gist.github.com/illicitonion/53d68708a1c4057ccdc7190d642d44f6

Are we using proc-quote wrong in some way? We'd love to get back to using it, as it's a really handy crate!

Thanks!

[Goncalerta]

I will investigate this when I have more time. Meanwhile, have you tried to use the original quote crate? It should be able to do most things this crate can, and because it is implemented in macro_rules, it should give a better performance than this one.

[illicitonion]

I just checked - the original quote crate took 88 seconds, so much closer to proc-quote.

[Goncalerta]

That is bad. I don't think I can surpass the speed of the quote crate in proc-quote, so any potential improvement will probably come from quote first.

@dtolnay what do you have to say about this?