Exonio.irr is slowly with Ruby 3.2.2

[gemitoytp]

Hi!

I have the following gist code:

https://gist.github.com/gemitoytp/eca40ae2c264f43cbebf96b6eb7338e4

If I use Ruby 3.1.4 is more fastest that Ruby 3.2.2 with exonio-0.7.0, check the following benchmark result:

Ruby 3.1.4

$ ruby -v                                                                        
ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [arm64-darwin22]

$ ruby exonio_irr_benchmark.rb
       user     system      total        real
Exonio.irr  0.001008   0.000062   0.001070 (  0.001062)

Ruby 3.2.2

$ ruby -v
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin22]

$ ruby exonio_irr_benchmark.rb
       user     system      total        real
Exonio.irr 86.791901   0.497656  87.289557 ( 87.318323)

I have an Apple M2 Pro with 16 GB of RAM

[israelb]

@gemitoytp Maybe the problem isn't Ruby. I think it's something wrong with the BigDecimal gem. I was able to test with several versions of it, and the issue with allocating too many objects in memory started from version 3.1.2.

Check out the huge difference:

allocated memory by gem
-----------------------------------
   7093916  bigdecimal-3.1.5
   1229367  exonio/lib
    340084  other

===============================================
allocated memory by gem
-----------------------------------
   7093916  bigdecimal-3.1.4
   1229367  exonio/lib
    340084  other

===============================================
allocated memory by gem
-----------------------------------
   7093916  bigdecimal-3.1.3
   1229367  exonio/lib
    340084  other

===============================================
allocated memory by gem
-----------------------------------
   7093980  bigdecimal-3.1.2
   1229367  exonio/lib
    340084  other

===============================================
allocated memory by gem
-----------------------------------
     83704  exonio/lib
     54556  bigdecimal-3.1.1
       240  other

I'll also provide the difference between versions 3.1.1 and 3.1.2. bigdecimal diff 3.1.1/3.1.2

Perhaps we can reach out to the BigDecimal team and ask them about it.

I just noticed that the error is related to this issue that has already been reported. Exponential growth in precision causing memory usage to spike as of 3.1.2