note: in the tests, we are setting a different variable @x
than the guard clause @x2
.
I tested a terciary ?:
vs the guard clause return if defined?()
and they were about the same for pass and fail case
test | int i/s | slower | text i/s | slower |
---|---|---|---|---|
eq2 | 6,315,053.7 i/s | same | 6,323,409.7 i/s | base |
neq2 | 6,281,137.2 i/s | same | 3,707,761.0 i/s | 1.71x |
eq | 5,978,924.2 i/s | same | 4,572,438.8 i/s | 1.38x |
include | 4,368,299.8 i/s | 1.45x | 4,349,531.4 i/s | 1.45x |
neq | 4,194,756.5 i/s | 1.51x | 4,170,358.7 i/s | 1.52x |
include2 | 3,704,824.1 i/s | 1.71x | 3,718,609.0 i/s | 1.70x |
thoughts:
int
andtext
represent the 2 use cases (pass the match and fail the match)int
is the 95% use case as most rails ids are integer. (my group uses bigint instead. I've used uuid in the past)- implementation was include2 (worst)
- changed to
include
(thanks @NickLaMuro) - His fix then triggered this gist - moving an array to a frozen constant is good
- just directly comparing to values is better
- trying to be cute and match to the 95% key may work, but there are probably better options
- shortening the list of compares is better
- unsure if I want to convert over to comparing with
:integer
and:bigint
- unsure if there are other cases - looking up the type of the primary key may overshadow any optimization we gain here
- only determining need to cast once probably has biggest benefit