Option for RAM Caching dependencies

[marcusobrien]

Describe the request

Compile times take too long.
IDe designers dont want to stop the auto dependency discovery that the IDE currently does, to keeps things easy for novice users.
Users want fasterer compile times.

Reading posts on here,

#1996

sounds like long build times is the scanning of libs for dependencies - and this involves disk access.
Can we have a mode called auto cache - that simply caches in RAM (so only for this session) on first compile, all the dependencies for the sketch - then no disk access needed for subsequent compiles/links.

Or what about a GreedyCacheMode, that when enabled reads into memory ALL arduino libs in paths, and use those to resolve/compile/link the binary. This would be much faster than scanning folders and files etc. Most people have a lot of RAM nowdays, so let the user choose how to make use of their own ram.

Describe the current behavior

Build scans for libraries and dependencies as their are no linker arguments provided by the user. This results in slow compile times for large projects with many headers, and external symbols etc (linker)

Arduino CLI version

2.1.0

Operating system

Windows

Operating system version

10

Additional context

No response

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the nightly build
• My request contains all necessary details

[PaulStoffregen]

what about a GreedyCacheMode, that when enabled reads into memory ALL arduino libs in paths, and use those to resolve/compile/link the binary

Today if you edit any library or header file, Arduino CLI notices the file's modification time is newer and rebuilds the file. In the case of headers, all files which include the header you've edited get rebuilt. Assuming this behavior would be maintained, even if a copy of all those files were held in RAM, the modification time on every file would still need to be checked to decide which files actually need to be recompiled.

Sadly, simply checking a file's metadata is slow on Windows. This message explains the reason why Windows file metadata is so slow. If you try Linux with a lot of RAM (for the kernel to cache filesystem metadata), you'll see quite a performance difference. Even if you have infinite RAM, Windows can't use it to cache filesystem metadata because of the way Microsoft designed their system.

Arduino CLI does cache dependency info already. You can see it with verbose mode. For example, compile a program twice and on the 2nd run you'll see it's using cached results.

Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GFX.cpp
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_GFX_Library/Adafruit_GrayOLED.cpp
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_GFX_Library/Adafruit_SPITFT.cpp
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_GFX_Library/glcdfont.c
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_BusIO/Adafruit_BusIO_Register.cpp
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_BusIO/Adafruit_I2CDevice.cpp
Using cached library dependencies for file: /home/paul/Arduino/libraries/Adafruit_BusIO/Adafruit_SPIDevice.cpp

The problem is even though the cached data can be used to avoid the work of recompiling, to check whether the cached data is fresh requires reading the modification time of every header file each includes. Just fetching the metadata is expensive on Windows.

However, perhaps the speed could be increased somewhat if Arduino CLI cached the filesystem modification times for headers. Then if you have many library files that include the same headers, it would only have to ask Windows for the modification time of each unique header only once.