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


mrkn (Kenta Murata) wrote:
> Eregon (Benoit Daloze) wrote:
> > I would be very happy to hear your opinion on this behavior.
> > I raised this as a separate issue: #7688.
> > 
> > I think it should be a spec change and this new behavior is actually helpful (and the old behavior harmful).
> 
> I think it is most important to release version 2.0, so I fixed this to keep compatible with 1.9.3's behavior.

I see, you are right, it is too late for any change like this.
----------------------------------------
Bug #7645: BigDecimal#== slow when compared to true/false
https://bugs.ruby-lang.org/issues/7645#change-35374

Author: mathie (Graeme Mathieson)
Status: Closed
Priority: Normal
Assignee: mrkn (Kenta Murata)
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/