From: "Eregon (Benoit Daloze)" Date: 2013-01-02T05:24:08+09:00 Subject: [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: . 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/