3 ms·
And specifically proc-macros that parse rust-like syntax. It's the `syn` library that's slow. Proc macros that have a custom parser tend to be quite fast.
by nicoburns 5y ago
And specifically proc-macros that parse rust-like syntax. It's the `syn` library that's slow. Proc macros that have a custom parser tend to be quite fast.
- the_duke 5y agoInteresting, I always assumed that syn was fast enough to not be a bottleneck. Do you have some related benchmarks, eg comparing it to the rustc and rust-analyzer parsers?
- nicoburns 5y agoI don't, but I've definitely seen examples of non-syn proc macros that were super-fast.
- matklad 5y agoThis is more nuanced, as there are three separate components: * time to compile the syn itself * time to run syn on the inputs * time to compile whatever syn generated I didn’t do a super thorough studies of things, but my impression is that 2, performance of syn itself, is rarely an issue. Most of the time it is 1) (and the associated problem of decreased build parallelism because half of the crates wait for syn to compile) and 3). To get a feeling how costly a simple proc macro is, run this benchmark: https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037bc0925a6a84174566eb1/tests/it/main.rs#L441 https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....