Issue #15589 has been updated by mame (Yusuke Endoh).


> I do not know how much work it would be to make .zero? as fast as == 0

In fact, it is easy to add a new special instruction, say `opt_zero_p`, for `.zero?`.  And if we add only `opt_zero_p`, it will not cause a big problem.

However, there are many other methods that are much more frequent than `.zero?`.  Adding all of them will cause two problems:

* increases the maintenance cost of the VM
* increases the footprint of the interpreter and even degrade the whole performance because of instruction cache miss

So, we need to carefully choose the set of the methods that deserve special handling.

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

* 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>