Front page | perl.datetime |
Postings from May 2012
Re: DateTime performance
Thread Previous
|
Thread Next
From:
Rick Measham
Date:
May 3, 2012 02:57
Subject:
Re: DateTime performance
Message ID:
E2CACD66-BA6D-4E7A-A1ED-CA6BCA19AF48@measham.id.au
In the spirit of TIMTOWTDI, there's my DateTime::LazyInit module which I wrote for this sort of case. It only inflates to a full DateTime object when you call methods that aren't "simple".
http://search.cpan.org/~rickm/DateTime-LazyInit-1.0200/lib/DateTime/LazyInit.pm
Caveat: I haven't tested it against any recent DateTime releases.
Cheers!
Rick Measham
📱
On 02/05/2012, at 8:29, "Philipp K. Janert" <janert@ieee.org> wrote:
>
> Question:
>
> When using DateTime for a large number of
> instances, it becomes a serious performance
> drag.
>
> A typical application for me involves things like
> log files: I use DateTime to translate the timestamps
> in these files into a canonical format, and then get
> information such as "day-of-week" or "time-of-day"
> from DateTime.
>
> However, when working through a files with a few
> tens of millions of records, DateTime turns into a
> REAL drag on performance.
>
> Is this expected behavior? And are there access
> patterns that I can use to mitigate this effect?
> (I tried to supply a time_zone explicitly, but that
> does not seem to improve things significantly.)
>
> Best,
>
> Ph.
>
> --
> Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au
> Click here to report this message as spam:
> https://login.mailguard.com.au/report/1EEXMobD68/14EZiTvCo3I3sbAw7UgxdE/0
>
--
Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au
Thread Previous
|
Thread Next