GitHub user ffbin opened a pull request:
https://github.com/apache/flink/pull/1024
[FLINK-2530]optimize equal() of AcknowledgeCheckpoint
optimize repeated check of this.state == null
You can merge this pull request into a Git repository by running:
$ git pull
Github user zentol commented on the pull request:
https://github.com/apache/flink/pull/1024#issuecomment-131512254
i don't think these statements are equivalent.
Assume that this.state == null and that.state != null.
In the original version we evaluate that.state ==
Github user zentol commented on the pull request:
https://github.com/apache/flink/pull/1024#issuecomment-131534953
Looking at the pure logic this would work, but you can't remove that.state
!= null since that could result in a NullPointerException inside equals.
---
If your project
Github user StephanEwen commented on the pull request:
https://github.com/apache/flink/pull/1024#issuecomment-131577837
Is this really in need of optimization? It is written failsafe, where it
does not crash even if `state` does not handle null values properly. This is
good, because
Github user ffbin commented on the pull request:
https://github.com/apache/flink/pull/1024#issuecomment-131523209
@zentol hi. You are right.I want to change
(this.state == null ? that.state == null : (that.state != null
this.state.equals(that.state))) to
(this.state == null
Github user ffbin closed the pull request at:
https://github.com/apache/flink/pull/1024
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user ffbin commented on the pull request:
https://github.com/apache/flink/pull/1024#issuecomment-131657696
@zentol @StephanEwen Thanks.This is not performance critical code and some
check is better.
---
If your project is set up for it, you can reply to this email and have
