pnowojski commented on a change in pull request #8124: [FLINK-11877] Implement the runtime handling of the InputSelectable interface URL: https://github.com/apache/flink/pull/8124#discussion_r276202913
########## File path: flink-streaming-java/src/test/java/org/apache/flink/streaming/runtime/io/benchmark/StreamTaskNonSelectableInputThroughputBenchmark.java ########## @@ -0,0 +1,122 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.flink.streaming.runtime.io.benchmark; + +import org.apache.flink.runtime.io.network.partition.consumer.IterableInputChannel; +import org.apache.flink.streaming.runtime.io.StreamTwoInputProcessor; +import org.apache.flink.streaming.runtime.io.benchmark.StreamTaskInputBenchmarkEnvironment.ProcessorAndChannels; + +import java.io.IOException; +import java.util.List; + +/** + * Task-input (non-selectable) throughput benchmarks executed by the external + * <a href="https://github.com/dataArtisans/flink-benchmarks";>flink-benchmarks</a> project. + */ +public class StreamTaskNonSelectableInputThroughputBenchmark extends StreamTaskInputThroughputBenchmarkBase { + + public void setUp(int numInputGates, int numChannelsPerGate, long numRecordsPerChannel) throws Exception { + setUp( + numInputGates, numInputGates, + numChannelsPerGate, numChannelsPerGate, + numRecordsPerChannel, numRecordsPerChannel, + new SummingLongStreamOperator()); + } + + @Override + protected AbstractTaskInputProcessorThread createProcessorThread( + int numInputGates1, + int numInputGates2, + int numChannels1PerGate, + int numChannels2PerGate, + long numRecords1PerChannel, + long numRecords2PerChannel, + long inputValue1, + long inputValue2, + SummingLongStreamOperator streamOperator) throws IOException { + + ProcessorAndChannels<StreamTwoInputProcessor<?, ?>, IterableInputChannel> processorAndChannels = + environment.createTwoInputProcessor( + numInputGates1, + numInputGates2, + numChannels1PerGate, + numChannels2PerGate, + numRecords1PerChannel, + numRecords2PerChannel, + 1, + 2, + streamOperator); + + return new StreamTwoInputProcessorThread( + processorAndChannels.processor(), + processorAndChannels.channels(), + streamOperator); + } + + // ------------------------------------------------------------------------ + // Utilities + // ------------------------------------------------------------------------ + + private static class StreamTwoInputProcessorThread extends AbstractTaskInputProcessorThread { + + private final StreamTwoInputProcessor<?, ?> inputProcessor; + + private final SummingLongStreamOperator streamOperator; + + private volatile boolean continuousProcessing = true; Review comment: still there is a performance downside, that you are not benchmarking the `StreamTwoInputProcessor` but also this `volatile`. If it's supposed to be an equivalent of `running` from task, we should benchmark the task class itself, not imitate it by copy/pasting the code. If the implementation of `Task` changes and we drop `volatile boolean running` there, this `volatile boolean continuousProcessing` would be outdated. In other words, we should either: 1. benchmark Task classes, and that would include any potential existing `volatile boolean running` 2. benchmark processors, but in that case we shouldn't be adding extra overhead. I guess that if we drop the outer loop that we were discussing in other comment, there won't be a need for this `volatile continuousProcessing` flag and we can safely benchmark processors without adding extra overhead, right? ---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
