Skip Menu |

This queue is for tickets about the OLE-Storage_Lite CPAN distribution.

Report information
The Basics
Id: 31006
Status: resolved
Priority: 0/
Queue: OLE-Storage_Lite

Owner: jmcnamara [...]
Requestors: jik [...]

Bug Information
Severity: Important
Broken in: 0.14
Fixed in: (no value)


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, 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
--- 2007-11-27 11:07:36.625000000 -0500 +++ 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 701b
Hi, Thanks for that. I had one other report about this but I couldn't reproduce it apart from profiling it down to the OLEDate2Local function. At the time I considered replacing the BigInt handling with some simpler routines that shifted the OLE date epoch to the Unix epoch and then localtime. Something along the lines of the following (but without Date::Calc): I didn't have enough time or interest however. :-) I am the maintainer and not the author. If you are interested would you care to investigate this possibility? With the proviso that it may not be worth pursuing if your patch eliminates the problem sufficiently. John. --
Subject: Re: [ #31006] Math-BigInt performance degradation causes major OLE-Storage_Lite performance degradation, with fix
Date: Thu, 29 Nov 2007 22:29:09 -0500
To: bug-OLE-Storage_Lite [...]
From: Jonathan Kamens <jik [...]>
Download (untitled) / with headers
text/plain 320b
I don't see any reason to investigate another solution when the one I suggested works just fine. Certainly, it won't degrade the accuracy of the code, and it'll definitely run faster than what's there now, so if neither of us has time to investigate different solutions, I think you should accept my patch. jik
Download (untitled) / with headers
text/plain 163b
On Thu Nov 29 22:29:51 2007, JIK wrote: Show quoted text
> I think you should accept my patch.
I hadn't intended not to. I'll upload a new release at the weekend. John. --
Patched in version 0.15. John. --

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

Please report any issues with to