rust dev tools slowness due to embedded DATA obj in skeleton

[GerardGarcia]

That may be a silly question since I may be missing something obvious, but how do set up your project so cargo check, the rust-analyzer LSP server, and similar dev tools works fast enough for normal usage (so I can see errors in my editor, autocompletion, and so on) when there is this huge DATA array embedded in the skeleton?

I have a pretty beefy M3 and I don't think my BPF object is particularly big (4.3MB compiled in a previous step without using libbpf-cargo) but my impression is that due to having it embedded in the skel.rs file that libbpf-cargo generates, these tools are barely usable. I've tried to exclude the whole skeleton but without much success and well, I would prefer to not exclude it completely.

Any tips?

[danielocfb]

Haven't had this problem yet, to be honest.

I've tried to exclude the whole skeleton but without much success

What does this mean? You excluded it and nothing changed?

FWIW, there is rust-lang/rust-analyzer#18907 hot off the press, which may be helpful. Not sure.

[GerardGarcia]

What does this mean? You excluded it and nothing changed?

I mean I was not able to exclude it from everywhere, I may need to spend more time adjusting configs but I imagined someone else was having these problems so I wanted to ask for tips first. I usually develop using neovim although I switched to vscode because it seemed that rust-analyzer was better configured oob.

There were some other issues in neovim other than rust-analyzer LSP being slow. IIRC treesitter hanged for a few minutes (and blocked neovim completely) every time I opened the skeleton file. I tried to not open it but it was really annoying when I jumped to a symbol defined in the skel without realizing it would open it. When I profiled it, it was mostly stuck parsing the file. Now I have a different neovim config and is not happening anymore.

In vscode, I have this config and the rust-analyzer LSP server works fast (although without being able to use the symbols defined in the skel) but cargo check still seems slow (but being async is not too bad). For example, it takes 2-3s to run when there is a minor change like renaming a var in a file.

{
    "files.watcherExclude": {
        "src/bpf/*.skel.rs": true
    },
    "rust-analyzer.cargo.buildScripts.enable": false,
    "rust-analyzer.cargo.buildScripts.rebuildOnSave": false,
    "rust-analyzer.files.excludeDirs": [
        "src/bpf/"
    ]
}

It is usable, but not ideal. If I manually remove the whole contents of the DATA array all the tools run fast without having to exclude any file or disable any option and of course, knowing all the symbols.

[GerardGarcia]

After replacing my M3 with an Intel machine with natively installed Ubuntu Linux instead of the arm64 Linux VM I was using in the M3 I do not see any slowness anymore. Not sure what was exactly the issue but I imagine under more common setups this is not an issue.