ESP-IDF very slow compilation from vscode

zazas321
Posts: 231
Joined: Mon Feb 01, 2021 9:41 am

ESP-IDF very slow compilation from vscode

Postby zazas321 » Fri Feb 18, 2022 11:58 am

Hello. I am using vscode and esp-idf extension to program ESP32 devices. I have noticed that whenever I change the menuconfig or clean the project, the build time is around 3-4 minutes. That seems insanely high. Is there any way to optimise it a little bit? Is there anyone who are having simmilar issues?

When I click build on the vscode, I can see that it executes ninja:

Code: Select all

> Executing task: ninja  <

User avatar
ESP_Roland
Posts: 261
Joined: Tue Oct 09, 2018 10:28 am

Re: ESP-IDF very slow compilation from vscode

Postby ESP_Roland » Wed Feb 23, 2022 8:37 am

This is usually caused by antivirus checks (if you are on Windows). In that case, you can re-run the Windows Tool Installer and select the appropriate Antivirus and Windows defender options. If you don't want to re-run it then it is possible to manually invoke the tool: https://github.com/espressif/idf-env#wo ... -antivirus

Another possibility to improve build time is to use ccache: https://docs.espressif.com/projects/esp ... py-options

phatpaul
Posts: 110
Joined: Fri Aug 24, 2018 1:14 pm

Re: ESP-IDF very slow compilation from vscode

Postby phatpaul » Thu Aug 17, 2023 8:10 pm

Whoa! adding --ccache makes a huge difference. Wonder why that isn't the default?
Thanks for the tips.

RandomInternetGuy
Posts: 52
Joined: Fri Aug 11, 2023 4:56 am

Re: ESP-IDF very slow compilation from vscode

Postby RandomInternetGuy » Tue Aug 22, 2023 8:20 am

ccache is awesome until it isn't.

IF you know it's there, you know it's not perfect, and know there's a secret layer of voodoo between your source code and what your device sees in the executable, it can be awesome. If any one of those systems breaks down, you can spend a lot of nerd points in your life (and you only get just so many....) before you even know where to LOOK for a problem, let alone finding one.

The day you find your group silently rolled out a ccache environment that's on a machine you can't see, but that has error messages redirected to null AND has a failed/failing/full disk can be a very bad day indeed. It begins with "I changed X but Y didn't change, escalates to "I compiled the objects to source via -S -o foo.o ... and get a different result when I view the source vs when I objdump --disassemble the object" and, finally, "I made the first line of main() into an abort(), but this program is still running, WTH?" can be a very long day. I've encountered all these progressions. I encountered two of them today.

Without inside knowledge on this specific case, I'd venture that THIS, not some secret desire to make your builds slow, is why tools vendors generally don't default aggressive write caching to ON. It's better to be slower and deterministic than faster and involving another full layer between the human/source code creator and the executor. When it works 100%, it's great, but when it's wrong, it doesn't matter how quickly your code doesn't work.

Using ccache is awesome. Debugging ccache is sort of terrible. Debugging ccache when you don't know it's involved in the process is totally terrible.

Of COURSE, if your build is on Windows and you're spending a couple of cores on preventing strangers from using your computer to send malware to the entire world, you deserve what you got. :-)

Who is online

Users browsing this forum: Gaston1980 and 77 guests