Short-circuit chained lazy calls once a nil is encountered.#5307
Merged
headius merged 2 commits intojruby:masterfrom Sep 4, 2018
Merged
Short-circuit chained lazy calls once a nil is encountered.#5307headius merged 2 commits intojruby:masterfrom
headius merged 2 commits intojruby:masterfrom
Conversation
The original logic would continue to check nil for each lazy call, even after a nil resulted from one of the elements. This new logic will always branch to the end of the chain if a nil is encountered anywhere along the way. This combined with the indy BNil patch produces the best perf for a benchmark of a long chain of calls against an always-nil value.
Member
Author
|
Ok, so benchmarks. There's two versions of bench here; one has a chain that terminates immediately (first receiver is already nil. The second one terminates after the first call (first receiver is not nil but returns nil). class X
def y
nil
end
end;
def foo(x)
x&.y&.y&.y&.y&.y&.y&.y&.y&.y&.y
end
loop {
t = Time.now
i = 0
x = X.new # replace with x = nil to test immediate short-circuit
while i < 100_000_000
foo(x)
i += 1
end
puts Time.now - t
}Performance on JDK8 before and after, with and without indy: Oddly enough something seems to have broken performance on GraalVM EE for this case: If I modify the bench to short-circuit immediately (first receiver is nil), GraalVM does much better: I'm unsure why indy degrades the not-quite-immediate-short-circuit case so severely on GraalVM. Graal JIT in a recent JDK 11 build also degrades the same way. |
Member
Author
|
Ok, the indy + graal performance degradation appears to be something unrelated to BNil and lazy operator work from today. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The original logic would continue to check nil for each lazy call,
even after a nil resulted from one of the elements. This new logic
will always branch to the end of the chain if a nil is encountered
anywhere along the way.
This combined with the indy BNil patch produces the best perf for
a benchmark of a long chain of calls against an always-nil value.