rust-analyzer: rust-analyzer is slow to compile

Both ra_hir and ra_ide_api are really slow to compiler, which makes fix & test loop rather frustrating. Note that tests are extremely fast themselves, it’s compile time that hurts us badly.

We need to do something with it…

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 8
  • Comments: 58 (57 by maintainers)

Commits related to this issue

Most upvoted comments

Some measurements from today and a time before ra_ide_db introduction https://gist.github.com/matklad/9657836aa0a9ad226a95b6f18d55b3fc

image

image

😦 😦 😦

image

Codegen seems to be taking an awful lot of time…

With debug=0:

image

But overall that’s just a tiny improvement.

After #5242:

image

Much more reasonable!

One of my tests is to compile a new crate containing only this code:

use hir::Semantics;
use ra_syntax::{ast, AstNode, SyntaxNode};

pub struct MatchFinder<'db> {
    sema: Semantics<'db, ra_ide_db::RootDatabase>,
}

impl<'db> MatchFinder<'db> {
    pub fn new(db: &'db ra_ide_db::RootDatabase) -> MatchFinder<'db> {
        MatchFinder { sema: Semantics::new(db) }
    }

    pub fn find_matches(&self, code: &SyntaxNode) {
        if let Some(macro_call) = ast::MacroCall::cast(code.clone()) {
            self.sema.expand(&macro_call);
        }
    }
}

It takes 11.5 seconds (vs. ~35 last week).

To things jump at me as odd:

  • it feels like ssr should not be that heavy
  • chalk is too light

On Wednesday, 1 July 2020, Laurențiu Nicola notifications@github.com wrote:

It feels like we’re getting slower and slower:

[image: image] https://user-images.githubusercontent.com/308347/86206821-f093b080-bb75-11ea-815d-9973bee870cb.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rust-analyzer/rust-analyzer/issues/1987#issuecomment-652202248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANB3M7FRVZECURZQ77T3GTRZLDOTANCNFSM4I7OUNRA .

And the one on GitHub is presumably linked statically (but still stripped).

with lto=false it is somewhat faster, but the general picture is the same

https://gist.github.com/matklad/c80618d9328546ca28f06ebe9022a327

image

Hm, should we put debug=0 into Cargo.toml? I think I personally can live with that, especially if it makes printf debugging faster 😃

We loose line numbers in backtraces, but I think I rarely look at backtraces (but we should retain debug=1 for releases, so that folks can get a useful backtraces from the debugger).

On the side note, one of the things I miss most from IntelliJ is the ability to colorize and linkify backtraces. If we could link rust::paths from backtraces to functions, that would be sooo helpful.

Hm, that reminds me that we should set debug = 1 for the dev profile, to save some disk space…