Issue #15589 has been updated by Eregon (Benoit Daloze).


If zero? was written in Ruby (like it is in Rubinius & TruffleRuby), and Ruby inlining was implemented (TruffleRuby does), then there should be very little difference once #zero? is compiled by the JIT.

That said, I am unsure if the difference ever matters in real-world workloads: it seems unlikely for #zero? to be a significant bottleneck for an application.

MJIT already achieves around 24Mi/s for `== 0` and 20Mi/s for #zero? (and TruffleRuby 193Mi/s for both zero? and == 0, illustrating my point) on my laptop:

~~~ ruby
v = 0
r = true
benchmark("== 0") do
  r = (v == 0)
end
benchmark("zero?") do
  r = v.zero?
end
~~~
using `benchmark-interface --simple`.
That's counting some block overhead and reading/writing to captured variables though, otherwise the benchmark optimizes away in >1 billion i/s.

----------------------------------------
Bug #15589: `Numeric#zero?` is much slower than `== 0`
https://bugs.ruby-lang.org/issues/15589#change-76697

* Author: sawa (Tsuyoshi Sawada)
* Status: Open
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* Target version: 
* ruby -v: 2.6.1
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
My understanding is that the predicate method `Numeric#zero?` is not only a shorthand for `== 0`, but is also optimized for frequent patterns. If `zero?` is not faster than `== 0`, then it loses its reason for existence.

However, According to benchmarks on my environment, `number.zero?` is around 1.23 times to 1.64 times slower than `number == 0` when `number` is an `Integer`, `Rational`, or `Complex`. It is faster only when `number` is a `Float`.

And with `number.nonzero?`, it is even worse. It is about 1.88 times to 4.35 times slower than `number != 0`.

I think there is something wrong with this, and it should be possible to optimize these methods, which has somehow been missed.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>