| Subject: | Math-BigInt performance degradation causes major OLE-Storage_Lite performance degradation, with fix |
When we upgraded the appliance that runs our application from RHL9 to
CentOS 5, we discovered that a script we were using that uses OLE-
Storage_Lite was suddenly running an order of magnitude slower than it
had been before.
I used Devel::Profiler and Devel::SmallProf to profile the script, and
discovered that the performance degradation was happening inside
OLEDate2Local in Storage_Lite.pm, in particular on this line:
$iDt -= $iYDays;
Since $IDt is a Math::BigInt, this suggests a performance regression in
Math-BigInt. I'll take that up separately with the Math-BigInt
maintainers, but in the meantime, I came up with a performance
enhancement to OLE-Storage_Lite which is correct in any case,
regardless of whether Math-BigInt's performance has degraded.
The attached patch coerces a couple of BigInt's back to regular Perl
scalars at the point where they are no longer actually large enough to
need to be a BigInt, so that all subsequent math on those numbers is
done with fast Perl math code rather than slow BigInt code. On CentOS
5, this speeds up OLEDate2Local by an order of magnitude.
| Subject: | OLE-Storage_Lite-0.14-OLEDate2Local-BigInt.patch |
--- 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;