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
Download (untitled) / with headers
text/plain 658b
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.
Download (untitled) / with headers
text/plain 2.1k
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;
Download (untitled) / with headers
text/plain 129b
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!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.