Batch: Process-parallel directory scan and initial file read #426
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Initial implementation of simple parallelism in the batch-processing scheduler. This PR refactors the two "trivially parallel" steps of the Scheduler initialisation (scanning the source directories and parsing the full
Sourcefile
into IR) using Python's builtinProcessPoolExecutor
. It also adds a dummySerialExecutor
implementation that exposes the same interface, but works serially on the original process, thus keeping existing functionality available.In a little more detail:
Sourcefile
creation from Item creation and removeget_or_create_file_item_from_path
executor
object to the Scheduler that dummies to the providedSerialExecutor
ifnum_workers=0
is selected, and otherwise creates aProcessPoolExecutor(max_workers=num_workers)
.Sourcefile.from_path
on the executor by passing assembledfrontend_args
Sourcefile.make_complete
) using theexecutor.map
functionality over source objects and parser-args, before updating the returned copy of source on the accordingItem
sym.Cast
objects andModule
AST objectsPerformance
To test performance, I've mimicked the H24-dev Plan-generation (without explicitly provided header paths), but locally enabled full source parses in the plan step. When adding the new
ProcessPoolExecutor
but keeping the number of processors low, we can see a significant overhead of the process-pipe-and-serialisation mechanics, but increasing the number of process somewhat we can still get to a reasonable quality-of-life improvement.Sequential, equivalent to previous:
Sequential, but through
ProcessPoolExecutor
:And with 12 build processes: