[ruby-core:51216] [ruby-trunk - Bug #7645] BigDecimal#== slow when compared to true/false

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

File coerce.patch added

Hello,

This is a nice bug report!

So, BigDecimalCmp() calls rb_num_coerce_cmp() then do_coerce(), which tries to call #coerce on `true`, which generates a NoMethodError, which is rescued by rb_rescue() in do_coerce().

The coerce behavior is intended and useful for custom defined math types. But do_coerce() might be optimized by using rb_check_funcall() instead of rb_funcall()+rb_rescue(), therefore not generating the exception.

This would have the side effect of not swallowing other errors happening with the call to #coerce. I think this is desirable, but I am less sure about compatibility.

It also has a small overhead for the case #coerce is defined as it first checks with #respond_to?.

Here are my numbers.
From your code sample:
before:
== 0    2.43s
== true 7.60s
after
== 0    2.62s
== true 1.56s

Without accounting the BigDecimal creation:
Ran at 2013-01-01 21:12:17 with ruby 2.0.0dev (2013-01-02 trunk 38674) [x86_64-darwin10.8.0]
before:
== 0    1.204 袖s/i 賊 0.020 ( 1.7%) <=>   830 363 ips (iterations per second)
== true 6.780 袖s/i 賊 0.162 ( 2.4%) <=>   147 482 ips
after:
== 0    1.198 袖s/i 賊 0.019 ( 1.6%) <=>   834 794 ips
== true 212.0 ns/i 賊 2.189 ( 1.0%) <=> 4 716 687 ips

What do other committers think?
It passes test-all.

diff --git a/numeric.c b/numeric.c
index 52e2c36..880bef1 100644
--- a/numeric.c
+++ b/numeric.c
@@ -211,35 +211,22 @@ num_coerce(VALUE x, VALUE y)
     return rb_assoc_new(y, x);
 }
 
-static VALUE
-coerce_body(VALUE *x)
-{
-    return rb_funcall(x[1], id_coerce, 1, x[0]);
-}
-
-static VALUE
-coerce_rescue(VALUE *x)
-{
-    volatile VALUE v = rb_inspect(x[1]);
-
-    rb_raise(rb_eTypeError, "%s can't be coerced into %s",
-	     rb_special_const_p(x[1])?
-	     RSTRING_PTR(v):
-	     rb_obj_classname(x[1]),
-	     rb_obj_classname(x[0]));
-    return Qnil;		/* dummy */
-}
-
 static int
 do_coerce(VALUE *x, VALUE *y, int err)
 {
     VALUE ary;
-    VALUE a[2];
-
-    a[0] = *x; a[1] = *y;
 
-    ary = rb_rescue(coerce_body, (VALUE)a, err?coerce_rescue:0, (VALUE)a);
-    if (!RB_TYPE_P(ary, T_ARRAY) || RARRAY_LEN(ary) != 2) {
+    ary = rb_check_funcall(*y, id_coerce, 1, x);
+    if (ary == Qundef && err) {
+	volatile VALUE v = rb_inspect(*y);
+	rb_raise(rb_eTypeError, "%s can't be coerced into %s",
+		 rb_special_const_p(*y)?
+		 RSTRING_PTR(v):
+		 rb_obj_classname(*y),
+		 rb_obj_classname(*x));
+	return FALSE; /* dummy */
+    }
+    if (ary == Qundef || !RB_TYPE_P(ary, T_ARRAY) || RARRAY_LEN(ary) != 2) {
 	if (err) {
 	    rb_raise(rb_eTypeError, "coerce must return [x, y]");
 	}

----------------------------------------
Bug #7645: BigDecimal#== slow when compared to true/false
https://bugs.ruby-lang.org/issues/7645#change-35175

Author: mathie (Graeme Mathieson)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin12.2.0]


I was doing a spot of profiling on a Ruby on Rails application with perftools.rb and spotted that one particular chunk of code was spending a lot (nearly 60% in some tests) of its time in `BigDecimal#==`. It turns out that, when writing a numeric attribute in ActiveRecord, it compares the value to both `true` and `false`, and that appears to be the source of the slowness. I've reproduced this with the following sample code:

    require 'bigdecimal'

    1_000_000.times do
      BigDecimal('3') == true
    end

This snippet takes around 7 seconds to run on my Mac. If instead we compare with a number:

    require 'bigdecimal'

    1_000_000.times do
      BigDecimal('3') == 0
    end

the runtime drops to ~1.2 seconds. This seems suboptimal. I'm struggling to follow through the BigDecimal source code, but the profile output indicates that `BigDecimal#==` is causing a `NameError` exception to be raised, which it's then catching and returning a valid result.

I've reported this issue to the Rails tracker here: <https://github.com/rails/rails/issues/8673>. While there's an easy workaround for ActiveRecord (I hope, anyway!), it does strike me that BigDecimalCmp() could short-circuit and return something sensible if the comparison value is true, false or nil?

This is my first bug report to Ruby core, so apologies if it's not quite up to scratch. If you need any more information from me, please do ask. Thank you!


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