Open cmaglie opened 3 months ago
Attention: Patch coverage is 77.82910%
with 96 lines
in your changes missing coverage. Please review.
Project coverage is 67.87%. Comparing base (
ce4341f
) to head (87765a4
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
LGTM
Please check if the PR fulfills these requirements
See how to contribute
UPGRADING.md
has been updated with a migration guide (for breaking changes)configuration.schema.json
updated if new parameters are added.What kind of change does this PR introduce?
This is a tentative to improve compile speed by multi-threading the library discovery phase.
How library discovery works
The library discovery is a sequential process, and could be summarized as follows:
gcc -E ...
)Missing include file "xxx.h"
error then:xxx.h
is added to the includes path listThe above loop continues until one of the following happens:
missing include
Could this be multi-threaded?
The main issue here is that each run of
gcc -E ...
requires the includes path list determined by the previous iterations. At first sight, it seems a strictly sequential process.BTW, there are some strategies that we may use:
When a library is added to the queue, we may speculatively start a multithreaded compilation of the next files in the queue assuming no
missing include
errors will be produced. Most of the time this assumption turns out to be true and the time saved could be dramatic.We may leverage the "library detection cache" to spawn a speculative multithreaded compilation of all the files (predicting all the libraries added in the process), assuming that the
missing include
errors would be the same as the previous successful compilation as saved in the "library detection cache". In this case, we reproduce the same compiles as the previous build. The basic assumption is that the libraries detected will not change between compilations.If an unforeseen
missing include
error is detected, the speculative multithreaded compilation must be canceled and restarted (basically wasting the work done ahead of time). In a multi-core system, since the work "ahead" is done in parallel, the worst-case scenario should take nearly the same time as the "classic" non-multithreaded compile.Due to the complexity of these changes, I'll start this as a draft. I want to add integration tests to trigger edge cases before merging.
What is the current behavior?
What is the new behavior?
Compiles should in general be faster than before.
Does this PR introduce a breaking change, and is titled accordingly?
No
Other information