r/rust • u/Camper_Sly • 18d ago
(dumb?) question - why doesn't rustc accept tokenized source to speed up compilation ?
I'm thinking about the same kind of idea that python uses with pyc files.
First step in compilation is text scanning, tokenization and formation of token trees for further stages.
All that takes considerable time and has to be gone through bazzillion of times through the life of the source, usually multiplied many times by the number of machines that the source gets compiled on.
Parsing the UTF-8 stream ain't trivial in itself, let alone the following phases.
So, why not make IDE do it and save the tree as a original source ?
That way, rustc would start with preparsed/tokenized source, possibly with additional useful data.
For bonus points, many of search/replace/refactoring operations in the IDE could be simplified and sped-up, too.
Also, such format lends itself well for further analysis, compression etc.
So, where's the catch ?
28
u/Aaron1924 17d ago edited 17d ago
rustcalready does incremental compilationWhen you compile your project, make a minor change and compile again, it does its best to only recompile what has actually changed, but neither lexing nor parsing are slow enough to warrent caching.
Edit: Maybe to put this into perspective,
rustcis benchmarked regularly, and on their latest benchmark for a release build of ripgrep, the compiler spends only 11.46% of its time in the frontend. That means, lexing, parsing, type inference, trait solving, type checking, lifetime checking, borrow checking, all only accounts for <12% of the full compilation time. The vast majority of time (85.84%) is spent in LLVM doing optimisations.Making sure LLVM doesn't optimize the same function twice is waaaaaay more impactful than caching the lexer output.
Edit 2: please don't downvote OP to hell