When to box parsers?

[jimmycuadra]

I've noticed compilation times can be quite slow in my program. I've read in the docs and a few discussions that this is not unexpected for programs with lots of long parser chains and that boxing parsers can help reduce compilation times. I'm wondering if there's guidance on how to decide which parsers to box for this purpose without too much of a trade off.

I'm suspect that for my small program, I could probably just box all parsers and the dynamic dispatch wouldn't matter much, but I'm guessing there's a better approach. Is it just trial and error, boxing one at a time to see which ones have an effect on compilation times? Or is there something I should be looking for in a parser that makes it a good candidate for boxing?

[zesterer]

There is!

[jimmycuadra]

Ah yes, these are the docs I was referring to. I'm already using choice over or in most places. I guess I'll just try boxing everything! Doesn't seem like there's much downside.

[zesterer]

You'll find that 10% of .boxed()s make 90% of the difference to compilation time. You should only need to put it at the end of significant chunks of parser declarations.

[jimmycuadra]

Is there a benefit to boxing a choice combinator or does using choice over a chain of ors achieve the same improvement to compilation performance as boxing?

[zesterer]

It can still be beneficial in some cases. Boxing gives the compiler a shortcut: the compiler only has to prove that your parser implements the Parser trait once, rather than needing to prove it potentially many times over depending on how the parser is used. Ideally the compiler would simply cache that proof, but why it can't always do that is more a question for the Rust core devs 😀

I wouldn't think too hard about it, to be honest. If your compilation times are acceptable for you, then that's good enough. If not, then do a bit of strategic scattering of .boxed() until you're happy.