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

[rmm5t]

Suggestion:

BigDecimal.limit(128)
# OR
BigDecimal.limit(1024)

It appears anything greater than a limit of 10,000 really starts to slow things down, and BigDecimal's default is 0, which means no upper limit.

Limit the number of significant digits in newly created BigDecimal numbers to the specified value. Rounding is performed as necessary, as specified by BigDecimal.mode.

A limit of 0, the default, means no upper limit.