-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FLINK-19441][network] Avoid loading of ResultPartition wrapper class for consumable notifications when possible. #13548
Conversation
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Automated ChecksLast check on commit 3e996d9 (Tue Oct 06 14:58:11 UTC 2020) Warnings:
Mention the bot in a comment to re-run the automated checks. Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting find and idea. The final code looks a bit confusing.
I was wondering if we should move the factory method into Task to make it easier again to understand. I think having deployment descriptors leaked into PartitionWriter is a sign that the method is misplaced to being with.
…gResultPartitionWriterDecorator
3e996d9
to
d848698
Compare
… for consumable notifications when possible. This separates the factory method code from the wrapping class (by making the wrapping class an inner class). Not loading the wrapper class when not needed simplifies the JIT's job of optimizing method calls to the ResultPartition class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After offline discussion, I realized that ConsumableNotifyingResultPartitionWriterDecorator
is now a utility class, so LGTM.
d848698
to
16fb79e
Compare
Adjusted the code to make the role of the utility class more clear. |
What is the purpose of the change
A small code optimization attempting to reduce the virtual method call overhead on the per-record methods in
ResultPartition
.It does that by making the class wrapping the
ResultPartition
(formerlyConsumableNotifyingResultPartitionWriterDecorator
) a different class than the one with the factory method. That way, if the factory method never needs a wrapper class (under normal configuration, it never needs one) the wrapping class is never loaded, and the JIT can find out (through CHA) that only one implementation for the per-record methods onResultPartition
exists.Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
@Public(Evolving)
: noDocumentation