-
Notifications
You must be signed in to change notification settings - Fork 174
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
Optimize auto_notify
boolean check
#774
Merged
imjoehaines
merged 2 commits into
bugsnag:next
from
sambostock:optimize-auto-notify-boolean-check
Feb 1, 2023
Merged
Optimize auto_notify
boolean check
#774
imjoehaines
merged 2 commits into
bugsnag:next
from
sambostock:optimize-auto-notify-boolean-check
Feb 1, 2023
Conversation
This file contains 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
The current implementation checks if `auto_notify` is an instance of `TrueClass` or `FalseClass` (in that order). As this is a "hot path" as far as Bugsnag is concerned (runs on all notifications), we can consider applying the following optimizations: - `true` and `false` are singleton instances of `TrueClass` and `FalseClass`, respectively. Therefore, we can rely on the slightly faster `.equal?` check, which relies on object identity. - `false` is the default for the method, so is likely the most common usage, so we can invert the order of the check and check for `false` before `true`, to benefit from short circuiting in the more common case. This new implementation is faster in the `false` and non-boolean cases, and while it is slower in the `true` case (because of the order inversion), it is still faster than the previous approach was in the `false` case. We can test this using the following benchmark: require "benchmark/ips" [ false, # Default – Probably most common case true, # Override – Probably accounts for almost all other usage {}, # Deprecated – Probably barely any usage ].freeze.each do |auto_notify| Benchmark.ips do |x| x.compare! x.report("#{auto_notify}.is_a? TrueClass or #{auto_notify}.is_a? FalseClass (status quo)") do auto_notify.is_a? TrueClass or auto_notify.is_a? FalseClass end x.report("false.equal? #{auto_notify} or true.equal? #{auto_notify} (proposed) ") do false.equal? auto_notify or true.equal? auto_notify end end end which produces the following results: Implementation |`false` |`true` |`{}` ----------------------------------------------------------------------------|--------------------|--------------------|-------------------- `auto_notify.is_a? TrueClass or auto_notify.is_a? FalseClass` _(status quo)_|11.978M (± 0.6%) i/s|17.122M (± 1.3%) i/s|11.814M (± 0.5%) i/s `false.equal? auto_notify or true.equal? auto_notify` _(proposal)_ |17.955M (± 0.4%) i/s|13.553M (± 1.6%) i/s|13.420M (± 2.5%) i/s
Hey @sambostock, thanks for the PR. We will review and merge as soon as priorities allow. |
imjoehaines
previously approved these changes
Feb 1, 2023
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.
Thanks @sambostock!
This is a great PR description ⇔ code change ratio 😀
imjoehaines
approved these changes
Feb 1, 2023
Merged
This has been released in v6.25.2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Goal
This attempts to optimize a check that happens every time
Bugsnag.notify
is called.The current implementation checks if
auto_notify
is an instance ofTrueClass
orFalseClass
(in that order). As this is a "hot path" as far as Bugsnag is concerned (runs on all notifications), we can consider applying the following optimizations:true
andfalse
are singleton instances ofTrueClass
andFalseClass
, respectively. Therefore, we can rely on the slightly faster.equal?
check, which relies on object identity.false
is the default for the method, so is likely the most common usage, so we can invert the order of the check and check forfalse
beforetrue
, to benefit from short circuiting in the more common case.Design
This new implementation is faster in the
false
and non-boolean cases, and while it is slower in thetrue
case (because of the order inversion), it is still faster than the previous approach was in thefalse
case.It is safe because
true
andfalse
are singleton instances ofTrueClass
andFalseClass
, respectively.The order inversion is based on the assumption that
notify
is usually called withauto_notify = false
, as that is the default.Notably, the new implementation does not harm readability, and is arguably clearer.
produces the following results:
false
true
{}
auto_notify.is_a? TrueClass or auto_notify.is_a? FalseClass
(status quo)false.equal? auto_notify or true.equal? auto_notify
(proposal)Changeset
The
auto_notify
boolean check changes in the following ways:.equal?
is used instead ofis_a?
false
is checked beforetrue
)Testing
None of the behavior should have changed, so this does not introduce any new tests. A benchmark was used to see the difference.