Skip Menu |

This queue is for tickets about the Math-BigInt CPAN distribution.

Report information
The Basics
Id: 31010
Status: resolved
Priority: 0/
Queue: Math-BigInt

People
Owner: TELS [...] cpan.org
Requestors: jik [...] kamens.brookline.ma.us
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in:
  • 1.77
  • 1.78
  • 1.79
  • 1.80
  • 1.82
  • 1.83
  • 1.84
  • 1.85
  • 1.86
  • 1.87
Fixed in: (no value)



Subject: Drastic performance degradation between 1.63 and 1.77
As described in http://rt.cpan.org//Ticket/Display.html?id=31006, we encountered a huge Math-BigInt performance regression when upgrading from RHL9 to CentOS 5. In RHL9, the Math-BigInt version was 1.63; in CentOS 5, it's 1.77. I also tried the current version of Math-BigInt, Math-BigRat and bignum, and they had the same problem, so I assume that everything between 1.77 and 1.87 has this problem. You can reproduce the issue by invoking the function mentioned in that bug report; it takes a packed 8-byte integer, most significant byte first, which specifies the number of 100-nanosend intervals which have passed since January 1, 1601 (ugh!).
On Tue Nov 27 12:11:20 2007, JIK wrote: Show quoted text
> As described in http://rt.cpan.org//Ticket/Display.html?id=31006, we > encountered a huge Math-BigInt performance regression when upgrading > from RHL9 to CentOS 5. In RHL9, the Math-BigInt version was 1.63; in > CentOS 5, it's 1.77. I also tried the current version of Math-BigInt, > Math-BigRat and bignum, and they had the same problem, so I assume that > everything between 1.77 and 1.87 has this problem. You can reproduce > the issue by invoking the function mentioned in that bug report; it > takes a packed 8-byte integer, most significant byte first, which > specifies the number of 100-nanosend intervals which have passed since > January 1, 1601 (ugh!).
Sorry for not getting back earlier to you, I didn't get (once again *sigh*) the email from RT. Looking at the other bug report, I do not see an easy testcase, can you please create some (very) short testcase that I can run and see why it gets so much slower? A simple "$x = -$y" shouldn't get slower by an order of magnitude.
On Sat Dec 15 09:01:00 2007, TELS wrote: Show quoted text
> On Tue Nov 27 12:11:20 2007, JIK wrote:
> > As described in http://rt.cpan.org//Ticket/Display.html?id=31006, we > > encountered a huge Math-BigInt performance regression when upgrading > > from RHL9 to CentOS 5. In RHL9, the Math-BigInt version was 1.63; in > > CentOS 5, it's 1.77. I also tried the current version of Math-BigInt, > > Math-BigRat and bignum, and they had the same problem, so I assume that > > everything between 1.77 and 1.87 has this problem. You can reproduce > > the issue by invoking the function mentioned in that bug report; it > > takes a packed 8-byte integer, most significant byte first, which > > specifies the number of 100-nanosend intervals which have passed since > > January 1, 1601 (ugh!).
> > Sorry for not getting back earlier to you, I didn't get (once again > *sigh*) the email from RT. > > Looking at the other bug report, I do not see an easy testcase, can you > please create some (very) short testcase that I can run and see why it > gets so much slower? > > A simple "$x = -$y" shouldn't get slower by an order of magnitude. > >
Okay, sorry, I negleted to actually look at your patch and it is now clear why this slowdown happens: In old versions of BigInt, int() was not overloaded and thus the result was always truncated to a Perl scalar (effectively what numify() does). You patch basically restores that behaviour, truncating the result manually to a Perl scalar and thus making the subsequent calculations going faster. In general, use BigInt objects only if neccessary as they are quite slow (sorry about this - wish I could make them faster). --- Storage_Lite.pm.orig 2007-11-27 11:07:36.625000000 -0500 +++ Storage_Lite.pm 2007-11-27 11:08:27.843750000 -0500 @@ -1326,7 +1326,13 @@ my $iHSec = $iBigDt % 10000000; $iBigDt /= 10000000; my $iBigDay = int($iBigDt / (24*3600)) + 1; + if ($iBigDay->numify eq $iBigDay) { + $iBigDay = $iBigDay->numify; + } my $iTime = int($iBigDt % (24*3600)); + if ($iTime->numify eq $iTime) { + $iTime = $iTime->numify; + } #2. Year->Day(1601/1/2?) $iDt = $iBigDay; $iYear = 1601;
I am marking this issue as resolved. If it is still a problem for you, please re-open this bug by replying to this email. Thanks!