ESP-IDF very slow compilation from vscode

[zazas321]

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  <

[ESP_Roland]

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]

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

[RandomInternetGuy]

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.