Feature Request: option to stop LDF from running at every build

[hamishcunningham]

Could an option be added to pio run to turn off LDF for a build?

If I know that dependencies haven’t changed, I’d like not to take the time to run LDF by default, and so get a faster edit/compile/flash cycle.

(It doesn’t take too long, true, but when doing hundreds of builds during a coding session it adds up!)

Tnx!
H

@maxgerhardt confirmed that it doesn't currently seem possible to do this.

[ivankravets]

LDF typically needs <1sec to resolve project dependencies. If you have a lot of header files such as icons or fonts, it can slow down the resolving process. See example at https://community.platformio.org/t/scanning-dependencies-takes-more-than-90-seconds-every-build/36901/6?u=ivankravets

How many seconds does LDF take for your project?

[sylque]

In my small project, pre-upload steps take 25 seconds, although the project is already built.

Resolving dependencies takes 15 seconds (with 3 local libs and 5 github libs):

Processing m5StickCPlus2_debug (platform: espressif32; board: m5stick-c; framework: arduino)
-----------------------------------------------------------------------------------------------------------------
Library Manager: Installing symlink:../Fusion
Library Manager: Installing symlink:../Syl
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/m5stick-c.html
PLATFORM: Espressif 32 (6.5.0) > M5Stick-C
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
 - framework-arduinoespressif32 @ 3.20014.231204 (2.0.14)
 - tool-esptoolpy @ 1.40501.0 (4.5.1)
 - tool-mkfatfs @ 2.0.1
 - tool-mklittlefs @ 1.203.210628 (2.3)
 - tool-mkspiffs @ 2.230.0 (2.30)
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain+, Compatibility ~ soft
Found 45 compatible libraries
Scanning dependencies...
Dependency Graph
|-- ArduinoEigen @ 0.3.2+sha.8f073b5
|-- SparkFun BMI270 Arduino Library @ 1.0.2+sha.09d6aaf
|-- M5StickCPlus2 @ 1.0.2+sha.de5ea6c
|-- HardwareBLESerial-ESP32 @ 1.0.0+sha.99e55e0
|-- ESP32 BLE Arduino @ 2.0.0
|-- syl
|-- sylimu
|-- ArxTypeTraits @ 0.3.1

And then this guy alone takes 10 seconds, although the project is already compiled and there's no compiler output:

Building in debug mode

--- EDIT ---
Part of my problem was that my platformio.h contained the option lib_ldf_mode = chain+ (see here for more information). Removing this line (i.e. coming back to default option lib_ldf_mode = chain) reduced the "Resolving dependencies" time from 15s to 3s.

[loknath2002]

Hi,

LDF takes ages on my system too(20-30s). I am running on (i7-9750H CPU @ 2.60GHz, 2592 Mhz, Windows) I’ve tested builds on multiple desktops across different operating systems, and one thing I can guarantee is that it’s definitely not fast — at least not in my experience.

I already have LDF Mode set to OFF and Compatibility set to OFF. I was hoping that would reduce the total build time by shaving off the ~30 seconds where Python’s LDF process sits running in Task Manager.

My project already takes around 3 minutes total to build and upload, which is pretty rough. Am I missing something here? Why not just add an option to disable the whole thing entirely, like the OP suggested?

Library Manager: Installing >=1.0.0 && <2.0.0
Library Manager: Installing >=0.2.0 && <0.3.0
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/BOARD_VIEWE_UEDX80480050E_WB_A.html
PLATFORM: Espressif 32 (55.3.37) > Viewe UEDX80480050E-WB-A
HARDWARE: ESP32S3 240MHz, 320KB RAM, 16MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-builtin, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - contrib-piohome @ 3.4.4 
 - framework-arduinoespressif32 @ 3.3.7 
 - framework-arduinoespressif32-libs @ 5.5.0+sha.87912cd291 
 - tool-esptoolpy @ 5.1.2 
 - toolchain-xtensa-esp-elf @ 14.2.0+20251107
*** Applied include path shortening for 336 framework paths ***
*** Path length reduced from 40414 to ~13965 characters ***
*** Estimated savings: 25872 characters ***
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ off, Compatibility ~ off
Found 54 compatible libraries
Scanning dependencies...
Dependency Graph
|-- FS @ 3.3.7
|-- SPI @ 3.3.7
|-- SD @ 3.3.7
|-- Update @ 3.3.7
|-- Preferences @ 3.3.7
|-- esp-lib-utils @ 0.2.0+sha.bb9ea3d
|-- ESP32_IO_Expander @ 1.1.0+sha.e79a638
|-- ESP32_Display_Panel @ 1.0.4+sha.12a01d6
|-- lvgl @ 9.5.0+sha.85aa60d
|-- ArduinoJson @ 7.4.2+sha.733bc4e
|-- FastLED @ 3.10.3+sha.20667c3

[sylque]

@loknath2002

Am I missing something here?

Probably not. PlatformIO's build process is very slow, especially on Windows. Here are a few things you can do to speed it up, ordered by impact:

1. Whitelist in your Antivirus: Ensure that both the PlatformIO core folder (usually ~/.platformio) and your specific project folders are in your antivirus's ignore/exclusion list.

2. Use Native Linux: Compiling on a native Linux environment is significantly faster than on Windows. A quick note on WSL: While WSL will speed up your compile times, firmware flashing will be so tedious that it will offset the time you saved on build.

3. Enable build_cache_dir: This won't save you any time on the very first build, but it's a lifesaver for subsequent ones. It's especially helpful for mitigating PlatformIO's tendency to occasionally trigger a full rebuild for seemingly no reason.

4. Set lib_ldf_mode = off: but keep in mind that it can be painful to maintain since you might have to add some include paths by hand. Additionally, it is buggy under Windows: you may need to regularly delete the .pio/libdeps folder to clear erroneous "include not found" errors.

[loknath2002]

3. build_cache_dir

Thanks, switching to Linux and lib_ldf_mode = off seems the way to go for me. LDF process barely takes a second now.