I am using PIO v2.4.3 and Windows10 version 10.0.19042 Build 19042.
My problem is when I use esp32dev in platform.ini as default_envs, build time is about 180 seconds.
FMI: I use both NodeMCU and ESP32. when I use nodemcu as default_envs build time is about 30 seconds.
It was okay when I did use esp32dev in platformio.ini and the build time was something like nodemcu.
I don’t really know what changed that.
I just updated my windows and did remove and reinstal PIO again. But nothing happend.
I have seen multiple cases where the cause of this was an antivirus tool scanning all compiler invocations (C:\users\<user>\.platformio\packages\toolchain-xtensa32 etc) and/or the pio.exe binary and it had 0 to do with PlatformIO.
Please consider above photo that has been uploaded by me.
When Flash usage comes up to 90% it takes more than 2 minutes to build. When I keep the program on 88% usage of the flash, the build time is reduce on 57 seconds.
Could it be a problem of partition scheme?
The issue only happens on Windows not linux.
I mean by increasing the files of my project (up to 90% capacity of Flash of ESP32) the build time is increasing times two.
But on the other hand on another system with Linux based system and same hardware and same files the build time is lower than a minute.
I think if we had a ‘make compilation fast’ button we would have pressed it by now.
Can the issue by synthetically recreated by creating a project with a constantd data array that, when the size crosses a certain boundary so that total flash usage in the standard partition table goes beyond 90%, compilation takes twice as long when compared to shortly before the boundary?
Well trying to create a project with same size was really messy. instead of that I did add all .h files (That I had been deveoped) in “include” folder.
It scanned in higher speed but I gained lots of undefined reference warnings. So unfortunately it did not got compiled properly.
Doing that without adding the corresponding .cpp/.c files will lead to undefined references, as .h files only contain the declaration, but (usually) not the implementation.
I imaged that was possible with just a simple
// 512K
#define FLASH_ARR_SIZE (512 * 1024)
const uint8_t flash_arr[FLASH_ARR_SIZE] = {0x00};
// use reference somewhere, e.g. so that it does not get optimized away
Serial.println("Flash arr at 0x"+ String((uint32_t)&flash_arr, HEX));
Thank you Max for your following up. Well I did use .cpp in lib but in its folder. for example /lib/reading_data/reading_data.cpp but I faced that issue. I never used these style before and I will appreciate if you give me hand on it.
I think the problem is in dependencies not the size of used flash. When I am seeing the terminal in build time most of the time is paid for scanning the dependencies.
When I mentioned about 90% usage of flash I meant that if my program get bigger and bigger the compilation is getting too slow. and I did use the 90% as a evident for my self that above that level compilation time is about 180 seconds.
When I use older version of my program which it is light version the compilation time is about 40 seconds.
But if as you said you can measure a difference between Linux and Windows on the exact same project, then that hints at a problem. Otherwise its only natural that depending on the libraries (and lib_ldf_mode), library discovery gets slower.