AHeise commented on a change in pull request #12575:
URL: https://github.com/apache/flink/pull/12575#discussion_r441334032
##########
File path:
flink-streaming-java/src/main/java/org/apache/flink/streaming/runtime/io/CheckpointBarrierAligner.java
##########
@@ -46,14 +49,8 @@
private static final Logger LOG =
LoggerFactory.getLogger(CheckpointBarrierAligner.class);
- /** Used to get InputGate by channel index. */
- private final InputGate[] channelIndexToInputGate;
-
- /** Used to get channel index offset by InputGate. */
- private final Map<InputGate, Integer> inputGateToChannelIndexOffset;
-
/** Flags that indicate whether a channel is currently
blocked/buffered. */
- private final boolean[] blockedChannels;
+ private final Map<InputChannelInfo, Boolean> blockedChannels;
Review comment:
`HashSet#contains` uses `HashMap#containsKey`, which fetches the node of
the key. Without hash collisions and overflow lists, that is exactly the same.
The question is how many collisions we have. It may also depend on whether the
respective `Set` is mostly filled or empty (e.g., `blockedChannels` should be
mostly empty). We might want to potentially invert the current semantics to
keep them empty as long as possible.
My main motivation was to avoid adding anything to GC pressure and using
mostly a constant data structure as before to not change too much. I think I'd
leave it as is for now. We can revise it when we adjust the threading model of
Unaligner, which will be a major change on the code anyways.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
