You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Stephan Ewen (Jira)" <ji...@apache.org> on 2020/10/06 15:20:00 UTC
[jira] [Comment Edited] (FLINK-19441) Performance regression on
24.09.2020
[ https://issues.apache.org/jira/browse/FLINK-19441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208828#comment-17208828 ]
Stephan Ewen edited comment on FLINK-19441 at 10/6/20, 3:19 PM:
----------------------------------------------------------------
I could not find anything very suspicious in the code. In general, the code does look less complex not than before, does not have any new locks or volatile variable accesses, and seems to have the same number of virtual method calls:
* RecordWriter.emit(T record) (bi-morphic between {{ChannelSelectorRecordWriter}} and {{BroadcastRecordWriter}}.
* The record serialization (to byte buffer) is unchanged
* Because the record-to-buffer logic is in the {{ResultPartition}} now, there is one method on ResultPartition that is called per record now, rather than per buffer. That method is not virtual, though, there is only one active implementation.
One think we can investigate is the {{ConsumableNotifyingResultPartitionWriterDecorator}}. The class is always loaded, but never instantiated (only a static method is used). That means in CHA the JIT will find two methods for the last method mentioned above, but all call sites call the same one, so any profiling logic should be able to cut this out again.
Still, it is trivial to change the code so that the {{ConsumableNotifyingResultPartitionWriterDecorator}} code is never loaded.
Here is the PR for that: [https://github.com/apache/flink/pull/13548]
was (Author: stephanewen):
I could not find anything very suspicious in the code. In general, the code does look less complex not than before, does not have any new locks or volatile variable accesses, and seems to have the same number of virtual method calls:
- RecordWriter.emit(T record) (bi-morphic between {{ChannelSelectorRecordWriter}} and {{BroadcastRecordWriter}}.
- The record serialization (to byte buffer) is unchanged
- Because the record-to-buffer logic is in the {{ResultPartition}} now, there is one method on ResultPartition that is called per record now, rather than per buffer. That method is not virtual, though, there is only one active implementation.
One think we can investigate is the {{ConsumableNotifyingResultPartitionWriterDecorator}}. The class is always loaded, but never instantiated (only a static method is used). That means in CHA the JIT will find two methods for the last method mentioned above, but all call sites call the same one, so any profiling logic should be able to cut this out again.
Still, it is trivial to change the code so that the {{ConsumableNotifyingResultPartitionWriterDecorator}} code is never loaded.
Here is the PR for that: https://github.com/apache/flink/pull/13548
> Performance regression on 24.09.2020
> ------------------------------------
>
> Key: FLINK-19441
> URL: https://issues.apache.org/jira/browse/FLINK-19441
> Project: Flink
> Issue Type: Bug
> Reporter: Arvid Heise
> Assignee: Stephan Ewen
> Priority: Blocker
> Labels: pull-request-available
>
> A couple of benchmarks are showing a small performance regression on 24.09.2020:
> http://codespeed.dak8s.net:8000/timeline/?ben=globalWindow&env=2
> http://codespeed.dak8s.net:8000/timeline/?ben=tupleKeyBy&env=2 (?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)