From: "al2o3cr (Matt Jones)" <al2o3cr@...>
Date: 2013-01-02T04:45:59+09:00
Subject: [ruby-core:51215] [ruby-trunk - Bug #7645] BigDecimal#== slow when compared to true/false


Issue #7645 has been updated by al2o3cr (Matt Jones).


I've added some notes on the ticket on the Rails tracker - short story shorter, this particular case happens (AFAIK) because rb_num_coerce_cmp ends up looking for a coerce method on TrueClass.

Further insight from somebody who actually understands how this works would be appreciated. :)
----------------------------------------
Bug #7645: BigDecimal#== slow when compared to true/false
https://bugs.ruby-lang.org/issues/7645#change-35174

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/