[#51213] [ruby-trunk - Bug #7645][Open] BigDecimal#== slow when compared to true/false — "mathie (Graeme Mathieson)" <mathie@...>

11 messages 2013/01/01

[#51328] [ruby-trunk - Bug #7676][Open] Comparison of Float::NAN in array behaves unexpectedly — "simonrussell (Simon Russell)" <spam+ruby@...>

11 messages 2013/01/09

[#51347] [ruby-trunk - Bug #7679][Open] IRB history is broken — "zzak (Zachary Scott)" <zachary@...>

15 messages 2013/01/10

[#51389] [ruby-trunk - Bug #7688][Open] Error hiding with rb_rescue() on Comparable#==, #coerce and others — "Eregon (Benoit Daloze)" <redmine@...>

34 messages 2013/01/11

[#51430] [ruby-trunk - Bug #7696][Open] Lazy enumerators with state can't be rewound — "marcandre (Marc-Andre Lafortune)" <ruby-core@...>

15 messages 2013/01/14

[#51437] [ruby-trunk - Bug #7698][Open] RubyGems 2.0 has an incompatibility about installation of extension libraries — "mrkn (Kenta Murata)" <muraken@...>

21 messages 2013/01/15

[#51454] [CommonRuby - Feature #7701][Open] Non-optional (required) keyword args — "headius (Charles Nutter)" <headius@...>

31 messages 2013/01/15

[#51499] [ruby-trunk - Feature #7712][Open] Add .txt extensions to all plain-text documentation files for Windows users — "postmodern (Hal Brodigan)" <postmodern.mod3@...>

9 messages 2013/01/18

[#51619] [ruby-trunk - Feature #7738][Open] Deprecate Set#+ as an alias of Set#|, use it for symmetric difference. Introduce Hash#| for Hash#reverse_merge in Rails. — "alexeymuranov (Alexey Muranov)" <redmine@...>

11 messages 2013/01/24

[#51623] [ruby-trunk - Feature #7739][Open] Define Hash#| as Hash#reverse_merge in Rails — "alexeymuranov (Alexey Muranov)" <redmine@...>

24 messages 2013/01/24

[#51714] [CommonRuby - Feature #7747][Open] Expanded API for Binding semantics — "jballanc (Joshua Ballanco)" <jballanc@...>

19 messages 2013/01/27

[#51742] [ruby-trunk - Bug #7756][Open] clang 3.2 sees through UNINITIALIZED_VAR macro, gives warning — "drbrain (Eric Hodel)" <drbrain@...7.net>

10 messages 2013/01/29

[#51763] [ruby-trunk - Bug #7758][Open] Ruby on Windows crashes when active codepage is codepage 65001 and outputting unicode character — "joshc (Josh C)" <josh.nw@...>

16 messages 2013/01/30

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

From: "mathie (Graeme Mathieson)" <mathie@...>
Date: 2013-01-10 12:16:02 UTC
List: ruby-core #51344
Issue #7645 has been updated by mathie (Graeme Mathieson).


And thank you for fixing it! :) What would be the chances of the change being backported to 1.9.3, too?
----------------------------------------
Bug #7645: BigDecimal#== slow when compared to true/false
https://bugs.ruby-lang.org/issues/7645#change-35316

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/

In This Thread