From 11318ec510b41c6c0398a4e40f4a65fbb603a26d Mon Sep 17 00:00:00 2001 From: Nathan Harmata Date: Fri, 24 Feb 2017 20:20:57 +0000 Subject: Reword comment about the current implementation of ^. -- PiperOrigin-RevId: 148488719 MOS_MIGRATED_REVID=148488719 --- .../build/lib/query2/engine/BinaryOperatorExpression.java | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'src/main/java/com/google/devtools/build/lib/query2') diff --git a/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java b/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java index f2823be237..89374d0a94 100644 --- a/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java +++ b/src/main/java/com/google/devtools/build/lib/query2/engine/BinaryOperatorExpression.java @@ -90,10 +90,13 @@ public class BinaryOperatorExpression extends QueryExpression { return; } - // Intersection is not associative, so we are forced to pin both the left-hand and right-hand - // side of the operation at the same time. + // For each right-hand side operand, intersection cannot be performed in a streaming manner; the + // entire result of that operand is needed. So, in order to avoid pinning too much in memory at + // once, we process each right-hand side operand one at a time and throw away that operand's + // result. // TODO(bazel-team): Consider keeping just the name / label of the right-hand side results - // instead of the potentially heavy-weight instances of type T. + // instead of the potentially heavy-weight instances of type T. This would let us process all + // right-hand side operands in parallel without worrying about memory usage. Preconditions.checkState(operator == TokenKind.INTERSECT || operator == TokenKind.CARET, operator); for (int i = 1; i < operands.size(); i++) { -- cgit v1.2.3