From: "mrkn (Kenta Murata)" <muraken@...>
Date: 2013-01-03T14:48:14+09:00
Subject: [ruby-core:51228] [ruby-trunk - Bug #7645][Assigned] BigDecimal#== slow when compared to true/false


Issue #7645 has been updated by mrkn (Kenta Murata).

Status changed from Open to Assigned
Assignee set to mrkn (Kenta Murata)


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

Author: mathie (Graeme Mathieson)
Status: Assigned
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/