CPU utilization Very High

I run IDE 2.0.0-rc3 but even in 2.0.0 beta I noticed that the CPU utilization for Arduino related tasks is very high. even when it is doing "nothing" no compile, no upload, ...

my system configuration:

1 Like

Possibly related bug report:

I have the same ISSUE. Windows 10.

indeed.

This is a serious issue that is stopping me from using 2.0. It also appears in the nightly release.

On Windows 7, when nothing is happening (no compile, no upload, no edit) one of the Arduino processes, goes haywire and runs at full strength, grabbing 1 GB of RAM, then grows that to 2 GB withing 10 seconds, and then drops back to 1 GB, and the cycle continues. Obviously this is a runaway process doing nothing useful. Mouse becomes jerky and unusable. Perfmon shows that I have enough RAM, and I believe no paging is going on.

This happens from the very start of opening a sketch. It takes no time to go runaway.

Why is the indexer running when no edits are happening? And why should the indexer hug so much resources when it needs to run? Can one turn off the indexer?

The sketch is about 120 KB, and even a linear search should take just tens of milliseconds. And it should end if there are no edits. Thanks.

It should not be.

Not currently. There is a request for it here:

Is that the size of the code files, or of the compiled binary?

This is not only a matter of your sketch code. It is all the libraries and toolchain which might be used by your sketch. The Arduino Language Server must understand the entire program, which is much more than the code you see in the Arduino IDE editor.

Thank you for your reply. I am not sure if I understand the issue. The total binary code uploaded to the Mega is under 100 KB. Let's say the object code, including libraries, that includes all the definitions required and is in a binary form, can't be more than 1 MB. Why does the process need 2 GB of RAM and gobs of CPU cycles (of a 3 GHz Thinkpad running Windows 7)? What is it trying to do, when there are no changes to the code for half an hour or an hour? Linking object code is not cycle intensive. All compile and linkage data is already structured in object form.

This is not only a matter of your sketch code. It is all the libraries and toolchain which might be used by your sketch. The Arduino Language Server must understand the entire program, which is much more than the code you see in the Arduino IDE editor.

Understanding the entire program does not take hours of intense CPU cycles to the point that nothing much else can be accomplished on the PC. And this can run for at least an hour, in my last take, and never seems to come to an end. C++ is a detreministic language and the rules are well defined.

Clearly some processes are misbehaving, and it should not be too difficult for someone who understands the code to do a time analysis and discover the problem. I bring this up because I really want to use 2.0, but am unable to do so most of the time. And I don't think this issue is unique to me.

If this process was critical to the build, then you would think that the build would be suspended for an hour until the runaway process ends and produces the required information. But that does not happen. The build goes ahead and completes pretty fast, while that thing will run for an hour in the background. Thanks.

1 Like

@protovtol Thanks for mentioning the nightly release. Was gonna check it out but now I know it's no point.

Really wish this issue would be fixed soonish since it's also keeping me from using the IDE 2.0, but I guess there are more important things to implement/fix.

I should probably try to get the CLI working with VS Code or VS, and check back here in a few months to see if the IDE 2.0 is smoother to work with then.

Of course not. I never claimed it did. There is no doubt at all that the IDE is not working as expected for you. I'm only explaining that it isn't so simple as a "linear" search through the sketch code. It is necessary for the language server to do library discovery and then build the entire program, then analyze it. That process is very CPU intensive, but at a level orders of magnitude less than what you are observing.

Clearly.

The problem is that the people who understand the code can not reproduce the problem you report. This seems to only occur under some specific rare conditions.

Of course, your conditions are extra rare because you are using an operating system which is not supported and will never be tested against. But it seems that users of modern versions of Windows are also having this problem.

It is not. The language server is used only for code-aware features such as parameter hints, problem detection, hover, goto, etc. as well as auto format. It is only those features which are blocked by the program analysis process.

I will try to be more specific when this happens again, so that it may be reproduced.

If the language server is not required for the build, I don't mind to turn it off. If there is a way to do that, please let me know.

Thanks.

Thanks! It will be very valuable if someone can provide the developers with a set of instructions that can be followed to consistently reproduce the bug.

It is extremely difficult to investigate and prepare a fix for a bug when you can't reproduce it, or even when it only occurs intermittently under unknown conditions.

As I mentioned before, this is not currently possible. There is an existing formal request for it here:

Are there any logs we could provide? Should we try with different sketches? With or without custom libraries?

Aren't there any logs for the language server that can be enabled? If it's constantly monitoring the editor then it would be good to know what it's up to.

Yes. The IDE does generate logs.

Windows

C:\Users\<user name>\AppData\Roaming\Arduino IDE\

(i.e., %APPDATA%\Arduino IDE\)

Linux

Folder named undefined created under the path you started the IDE from (so most often in the undefined subfolder of the IDE installation folder, but not necessarily so)

(this odd and inconvenient location is caused by a bug, for which a fix is in progress)

macOS

~/Library/Logs/Arduino IDE/

The ideal is to determine the most minimal set of conditions required to reliably reproduce the issue.

For this purpose, a "bisection" approach is useful. The idea is to find a "bad" state (where the bug does occur) and a "good" state (where the bug does not occur), and then methodically reduce the differences between the two states until you find the closest sets of conditions that will produce a good and a bad state. Once you get there, the cause of the bug often becomes clear, or at least much easier to find and fix.

You already have an initial "bad" state, which is the complete environment which happens to exist on your computer.

The next step is to find an initial "good" state. For this, it is useful to eliminate as many factors as possible. You can provide the IDE with pretty much a completely clean environment as far as Arduino-specific things go by doing this:

Quit the Arduino IDE and then rename all of the following folders:


:warning: Make sure to preserve and keep track of the previous folders, since these might contain things that are essential to later reproduce the "bad" state.

Windows

  • %LOCALAPPDATA%\Arduino15
    (e.g., C:\Users\<username>\AppData\Local\Arduino15)
  • %HOMEPATH%\.arduinoIDE
    (e.g., C:\Users\<username>\.arduinoIDE)
  • %APPDATA%\arduino-ide
    (e.g., C:\Users\<user name>\AppData\Roaming\arduino-ide)
  • %APPDATA%\Arduino IDE\
    (e.g., C:\Users\<user name>\AppData\Roaming\Arduino IDE\)
  • %USERPROFILE%\Documents\Arduino
    (e.g., C:\Users\<user name>\Documents\Arduino)

Linux

  • ~/.arduino15
  • ~/.arduinoIDE
  • ~/.config/arduino-ide
  • Folder named undefined created under the path you start the IDE from.
  • ~/Arduino

macOS

  • ~/Library/Arduino15
  • ~/.arduinoIDE
  • ~/Library/Application Support/arduino-ide
  • ~/Library/Logs/Arduino IDE/
  • ~/Arduino

Now you need to test to see whether the problem still occurs.

If the problem does still occur after cleaning the Arduino environment, then this is your new "bad" state. You have now reduced a significant number of the potential factors. We know that the problem is not dependent on any special configuration, boards platforms, libraries, or sketches. Unfortunately, the path forward to finding the "good" state from here is not so clear because now we have all the rest of the environment on your system to consider. You might be able to use your intuition to identify candidate factors to eliminate (e.g., shut down other applications, disconnect devices from your computer, TEMPORARILY disable your antivirus)

If the problem does still occur after cleaning the Arduino environment, then this is your initial "good" state.

Once you have a "good" state, the bisection can begin. The most efficient bisection procedure is achieved by cutting the difference between the "good" and "bad" states in half each time. So you might try replacing two of the five directories you renamed. Now test again. Depending on the results, you now have either a new "good" state or a new "bad" state.

Continue repeating this process until you reach the atomic scale. For example if you found that the transition between "good" and "bad" is whether or not the old sketchbook folder is in place, you are not done. You must then start bisecting your way through the sketches and libraries within the sketchbook until you find the specific one(s) that produce the "bad" state.

Language server logging is disabled by default. You can enable them by following these instructions:

  1. Use the Ctrl/+Shift+P keyboard shortcut to open the "Command Palette" in the Arduino IDE.
  2. Select the "Preferences: Open Settings (UI)" command from the "Command Palette".
    The "Preferences" tab will now open in the editor panel.
  3. In the "Search Settings" field, type arduino.language.log
  4. Under the "Arduino > Language: Log", section, check the box next to "☐ True if the Arduino Language Server should generate log files into the sketch folder. Otherwise, false. It's false by default."
  5. Close the Preferences tab by clicking its X icon.

Log files will now be generated in the folder of each sketch you open in the Arduino IDE. You can quickly access the sketch folder by selecting Sketch > Show Sketch Folder from the Arduino IDE menus.

I did a clean install of the IDE 2.0 rc3 after renaming all directoeries that started with "Arduino".
I reinstalled the board manager and tested 2 sketches (ESP32 based) and all seems to be working fine. Low CPU and al "features" are working fine.

I will continue rebuilding my environment with all tools and libraries I had before and will let you know if I find anything!

I consistently get this problem, on two different computers, both running Win10.

A couple things I can add that might help, is say I have some code with an error (wavy red line under the issue), if I fix that error, the wavy red line remains, but also if I add/delete lines that cause the original faulty line of code to move line, the wavy red line remains on the exact same line/position.

I've also been coding with Visual Studio Code, and a couple of times, it has disabled auto-indexing for 10 minutes due to high CPU load, so I'm wondering if it could be some kind of issue with the underlying libraries being used?

The same computers handle auto-indexing fine in far larger projects when using full fat Visual Studio, so it's not like the computers are lacking processing power.

I'm very glad. Having a "bad" state and a "good" state is really good progress on troubleshooting the problem.

I noticed in the Arduino IDE warnings popping up from VScode warning that there are too many changes for VSCode to handle. Maybe VScode is implicated somehow? But after the reinstall I still had VSCode installed. I deleted it completely today just for checking that it is not part of the problem.

I've just looked at the repository, and Arduino IDE is using a VSCode extension, so it could be an issue with VSCode, rather than something specific to Arduino IDE.

Thank you. I'll see if I can find something out. It's probably gonna take a while though.

I'm guessing I'll be able to reproduce a good state if I don't use any libraries. But let's see.

I updated to RC4 today after deleting previous version (I was still in GOOD state, no issues with speed).
Now whenever I do make changes, even 1 char, to a file 'Building' is running for over 5 minutes at 12% CPU utiisation, followed by 'indexing' with same. This is an improvement over previous bad state, but still...

I did not load/install any other library or code.
I will again start from scratch, rename all Arduino directories, and reinstall.