Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Code completion using LSP and clangd
ollydbg:
One issue I see when using this plugin to parse the "Code::Blocks wx3.1.x (64bit)" cbp file.
In my computer, it takes more than 15 minutes, but from the "Code::Blocks Debug" log, I still see there are more than 280 more files need to be parsed. I see the "clangd.exe" eat about 75% of my cpu usage.
Is there option that we can only parse the active cpp files? Or active target source files. It looks like parsing the whole projects is really slow. :(
Thanks.
Pecan:
--- Quote from: ollydbg on February 03, 2022, 04:03:39 pm ---One issue I see when using this plugin to parse the "Code::Blocks wx3.1.x (64bit)" cbp file.
In my computer, it takes more than 15 minutes, but from the "Code::Blocks Debug" log, I still see there are more than 280 more files need to be parsed. I see the "clangd.exe" eat about 75% of my cpu usage.
Is there option that we can only parse the active cpp files? Or active target source files. It looks like parsing the whole projects is really slow. :(
Thanks.
--- End quote ---
You do not have to wait for all files to parse to use clangd.
Re: cpu usage. Set concurrently parsing threads to 2 at
Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads.
You should not worry about parsing going on in the background when restricting the number of parsing threads. My cpu usage is only 34% when I restrict concurrent parsing to 2 threads. And clangd response is quite fast.
(Intel i7 with 8 threads), only half of the threads are allowed to be used by clangd (hard coded), and only 2 to be used for background parsing (user option).
Active editors always get parsed first, then inactive editors, then background (non-editor) files. Newly opened editors go to the head of the queue and get parsed ahead of background files. Code completion requests also go to the head of queue.
There's no need to wait after the active editor is parsed (3 to 7 secs).
When I open CodeBlocks workspace (31_64), the active editor is indexed by clangd in a max of 7 seconds. All open editors have been indexed in less than 30 seconds. But I never have to wait more then 7 seconds to use code completion or other clangd features.
All those files being parsed in the background are used to fill the symbols tree. They're parsed in order of last-changed-time, then last-opened-time then all others so that the symbols tree gets filled with the most likely used files and symbols.
However, I'll put your suggestion in the ToDo list with an option to only parse files in editors. I don't know why you'd want to do that though, if you'll restrict the number of concurrent parsing threads.
ollydbg:
--- Quote from: Pecan on February 03, 2022, 07:20:50 pm ---
--- Quote from: ollydbg on February 03, 2022, 04:03:39 pm ---One issue I see when using this plugin to parse the "Code::Blocks wx3.1.x (64bit)" cbp file.
In my computer, it takes more than 15 minutes, but from the "Code::Blocks Debug" log, I still see there are more than 280 more files need to be parsed. I see the "clangd.exe" eat about 75% of my cpu usage.
Is there option that we can only parse the active cpp files? Or active target source files. It looks like parsing the whole projects is really slow. :(
Thanks.
--- End quote ---
You do not have to wait for all files to parse to use clangd.
Re: cpu usage. Set concurrently parsing threads to 2 at
Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads.
You should not worry about parsing going on in the background when restricting the number of parsing threads. My cpu usage is only 34% when I restrict concurrent parsing to 2 threads. And clangd response is quite fast.
(Intel i7 with 8 threads), only half of the threads are allowed to be used by clangd (hard coded), and only 2 to be used for background parsing (user option).
Active editors always get parsed first, then inactive editors, then background (non-editor) files. Newly opened editors go to the head of the queue and get parsed ahead of background files. Code completion requests also go to the head of queue.
There's no need to wait after the active editor is parsed (3 to 7 secs).
When I open CodeBlocks workspace (31_64), the active editor is indexed by clangd in a max of 7 seconds. All open editors have been indexed in less than 30 seconds. But I never have to wait more then 7 seconds to use code completion or other clangd features.
All those files being parsed in the background are used to fill the symbols tree. They're parsed in order of last-changed-time, then last-opened-time then all others so that the symbols tree gets filled with the most likely used files and symbols.
However, I'll put your suggestion in the ToDo list with an option to only parse files in editors. I don't know why you'd want to do that though, if you'll restrict the number of concurrent parsing threads.
--- End quote ---
Hi, thanks for the explanation.
I see in my setting: Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads.
This value is 1. (I haven't change this value, so the default value is 1)
By reading the source code, I see that if the value is 1, it means we only let the indexer use 1 thread of the total CPUs. In my PC, I have a CPU with 4 threads.
So, the expected cpu usage should be 25%, am I correct?
Here is a test:
I set the value: Setting->Editor->Clangd_Client->C.C++ parser(tab)->Concurrently parsing threads. to 2.
Now, I see that the cpu usage of clangd.exe is about 50%.
This is interesting, as 2 means 2/4 = 50%, which is correct.
But why the cpu usage is 75% if I set the value to 1?, I did test again, and see it is 25%, so sorry about that wrong report :(. I may looked wrongly at the the "System Idle process" cpu usage, because when the clangd.exe use 25% cpu, and the 75% cpu is from the Idle process.
ollydbg:
Maybe, the background index can be saved when we close the project, and reopen it when we load the project.
Here are some reference:
Qt Creator and clangd: An Introduction
It said the index can be persistent.
Some from clangd and llvm github and forum
Ability to move a project's clangd background index without triggering reindexing Issue #847 clangd/clangd
and Offline background index preparation Issue #587 clangd/clangd
and Using background and static indexes simultaneously for large codebases - Clang Frontend / clangd - LLVM Discussion Forums
Pecan:
--- Quote from: ollydbg on February 04, 2022, 07:55:56 am ---Maybe, the background index can be saved when we close the project, and reopen it when we load the project.
Here are some reference:
Qt Creator and clangd: An Introduction
It said the index can be persistent.
Some from clangd and llvm github and forum
Ability to move a project's clangd background index without triggering reindexing Issue #847 clangd/clangd
and Offline background index preparation Issue #587 clangd/clangd
and Using background and static indexes simultaneously for large codebases - Clang Frontend / clangd - LLVM Discussion Forums
--- End quote ---
Thanks for that information. I've often thought it would be nice to persist the clangd .cache and the symbols tree.
I'll put it on the ToDo list.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version