Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enabled a lens config CodeAction is very slow #17950

Open
A4-Tacks opened this issue Aug 23, 2024 · 9 comments
Open

enabled a lens config CodeAction is very slow #17950

A4-Tacks opened this issue Aug 23, 2024 · 9 comments
Labels
A-perf performance issues C-support Category: support questions

Comments

@A4-Tacks
Copy link

rust-analyzer version: rust-analyzer 1.82.0-nightly (7c2012d0 2024-07-26)

rustc version: rustc 1.82.0-nightly (7c2012d0e 2024-07-26)

editor or extension: Vim 9.1 coc-rust-analyzer

relevant settings:

{
    "rust-analyzer.updates.checkOnStartup": false,
    "rust-analyzer.lens.references.method.enable": true
}

code snippet to reproduce src/main.rs:

use std::{fmt::Display, ops::Deref};

#[derive(Debug, Clone, Eq)]
pub enum ParseLine<'a> {
    Label(&'a str),
    Args((), u32),
}
impl<'a> PartialEq for ParseLine<'a> {
    fn eq(&self, other: &Self) -> bool {
        match (self, other) {
            (Self::Label(l0), Self::Label(r0)) => l0 == r0,
            (Self::Args(l0, _), Self::Args(r0, _)) => l0 == r0,
            _ => false,
        }
    }
}
impl<'a> TryFrom<Vec<&'a str>> for ParseLine<'a> {
    type Error = ();

    fn try_from(_: Vec<&'a str>) -> Result<Self, Self::Error> {
        Ok(Self::Args((), 0))
    }
}
impl<'a> From<&'a str> for ParseLine<'a> {
    fn from(_: &'a str) -> Self {
        todo!()
    }
}
impl<'a> From<()> for ParseLine<'a> {
    fn from(_: ()) -> Self {
        todo!()
    }
}
impl<'a> Display for ParseLine<'a> {
    fn fmt(&self, _: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        todo!()
    }
}


fn main() { }

reproduce steps:

  1. open file src/main.rs, CPU Usage to 400%, Memory Usage to 851 MB
  2. in line 11 => l0 start CodeAction, is slow
  3. any edit and save file, and start CodeAction is very slow, Max CPU Usage to 700%, Memory Usage to 1350 MB
@A4-Tacks A4-Tacks added the C-bug Category: bug label Aug 23, 2024
@lnicola
Copy link
Member

lnicola commented Aug 24, 2024

I think there's a couple of different things here:

  • high CPU usage on load (especially if you have some dependencies in Cargo.toml) is probably the cache priming, which was added specifically for Vim users who open and close their editor all the time (as opposed to using :e); you can disable that
  • the memory usage seems fine, I get 650 MB in Code without cache priming
  • the references lens is very slow because it has to infer a lot of types, from all over the project, and it might be looking in places it shouldn't, which slows it down some more; we've recently merged some nice optimizations for reference search, though
  • I can't reproduce high CPU or memory usage when triggering the code actions at that location

@lnicola lnicola added C-support Category: support questions and removed C-bug Category: bug labels Aug 24, 2024
@A4-Tacks
Copy link
Author

A4-Tacks commented Aug 24, 2024

  • the references lens is very slow because it has to infer a lot of types, from all over the project, and it might be looking in places it shouldn't, which slows it down some more; we've recently merged some nice optimizations for reference search, though

I update to rust-analyzer 1.82.0-nightly (eff09483 2024-08-22)
still very slow, test crate dependencies count is zero

Screenshot_20240824_153639

  • high CPU usage on load (especially if you have some dependencies in Cargo.toml) is probably the cache priming, which was added specifically for Vim users who open and close their editor all the time (as opposed to using :e); you can disable that

The main slow is to edit and save


use "rust-analyzer.lens.references.method.enable": false and optional enable other lens, is fast

@lnicola
Copy link
Member

lnicola commented Aug 24, 2024

I update to rust-analyzer 1.82.0-nightly (eff09483 2024-08-22)

r-a changes only get into the rustup component once every week or so. The recent optimizations aren't there yet.

@A4-Tacks
Copy link
Author

A4-Tacks commented Aug 24, 2024

  • the memory usage seems fine, I get 650 MB in Code without cache priming

Wait, Is it still the same when "rust-analyzer.lens.references.method.enable": false ?
My memory usage is 405 MB

@lnicola
Copy link
Member

lnicola commented Aug 24, 2024

Yeah, 396 MB without the lens, 650 MB with it enabled. The issues with the lens are that:

@A4-Tacks
Copy link
Author

A4-Tacks commented Aug 24, 2024

I don't understand why other lens.references don't cause very slow performance

enable all lens (exclude rust-analyzer.lens.references.method.enable) is also fast

@lnicola
Copy link
Member

lnicola commented Aug 24, 2024

Because most of the others we can find without doing too much work. If you're looking at a ToString trait, you can search for the ToString text, make sure it's imported or qualified with the same path, and there you are, you either have a match or you didn't.

But if you're searching for new or eq, for each match we have to figure out where the method comes from (inherent or from a trait), and that's a lot more work.

Anyway, feel free to download a binary from https://github.com/rust-lang/rust-analyzer/releases/tag/2024-08-19 and see if it's any faster. Although:

This PR doesn't consider trait methods (they have a bunch of other problems), so no, this won't change.

@A4-Tacks
Copy link
Author

A4-Tacks commented Aug 24, 2024

Anyway, feel free to download a binary from https://github.com/rust-lang/rust-analyzer/releases/tag/2024-08-19 and see if it's any faster. Although:

I downloaded rust-analyzer-aarch64-unknown-linux-gnu.gz and use, but the still slow

rust-analyzer 0.3.1756-standalone (e402c494b 2023-12-01) is also slow

@lnicola lnicola added the A-perf performance issues label Sep 2, 2024
@NicolasWent
Copy link

Have the same issue here

I did not notice it before updating to latest version v0.3.2180 maybe it wasn't there before? Or it didn't gave "empty space" when we implement something

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-perf performance issues C-support Category: support questions
Projects
None yet
Development

No branches or pull requests

3 participants