Improve the prototype's performance with an additional thread pool.
While regular blaze uses 2 different instances of QueueVisitor with 2 different thread pool sizes for loading/analysis and execution, with merged Skyframe phases we have to use the same instance. Therefore, it caused a serious performance regression with the existing version of the prototype: the number of threads used for the loading/analysis phase was just too low for the execution phase.
To fix that, we add another ExecutorService with an appropriate thread pool size (equals to the value of --jobs) to the instance of QueueVisitor. This additional ExecutorService is reserved for the evaluation of "Execution phase" SkyKeys e.g. ActionLookupData or ArtifactNestedSetKey.
PiperOrigin-RevId: 400977343
diff --git a/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java b/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
index b0c9dec..ea261a9 100644
--- a/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
+++ b/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
@@ -203,7 +203,8 @@
TopLevelArtifactContext topLevelOptions,
ExtendedEventHandler eventHandler,
EventBus eventBus,
- boolean includeExecutionPhase)
+ boolean includeExecutionPhase,
+ int mergedPhasesExecutionJobsCount)
throws ViewCreationFailedException, InvalidConfigurationException, InterruptedException {
logger.atInfo().log("Starting analysis");
pollInterruptedStatus();
@@ -394,7 +395,8 @@
topLevelOptions,
keepGoing,
loadingPhaseThreads,
- viewOptions.cpuHeavySkyKeysThreadPoolSize);
+ viewOptions.cpuHeavySkyKeysThreadPoolSize,
+ mergedPhasesExecutionJobsCount);
}
} finally {
skyframeBuildView.clearInvalidatedActionLookupKeys();