Scanning dependencies and build time is slow

Development Platforms
1

HI Folks,

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.

Please inform me ASAP.

Regards

2

Please open PlatformIO Core CLI and share output of this command:

pio system info

Also, please share the contents of the platformio.ini file.

1 Like
3

This is the output:

image

this is ini:

[platformio]
default_envs = esp32dev

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino
upload_protocol = esptool
build_flags = 
    ${common_env_data.build_flags}
    -DESP32
upload_speed = 921600
monitor_speed = 19200
upload_port = COM7
lib_deps = 
    ${common_env_data.lib_deps_builtin}
    ${common_env_data.lib_deps_external}
    plerup/EspSoftwareSerial@6.12.7
4

The NodeMCU is based on ESP8266 dev-platform that uses a different toolchain in comparison to the ESP32.

What do you mean under “SLOW”. Does PlatformIO stick or just a lot of files are compiled?

5

There are lots of file to compile (example.h and example.cpp) and by slow I mean the build time is too long.

image
image986×194 6.89 KB

6

But It was not this long, After update of windows and PIO it could not work as proper as before.

7

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.

1 Like
8

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?

9

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.

10

Can you upload the project in which this occurs and tell us how to trigger it?

1 Like
11

I don’t think that could be possible for me.
I’m sorry is not there any other solution to speed up compile time in Windows ?

12

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?

1 Like
13

Right I wish the button would be find :slight_smile:
About the other part let me try, check and I will inform you.
Best Regards

14

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.

image

Any tips ?

15

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));

is it not?

16

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.

17

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.

2 Likes