I love and use DateTime for for 10s of millions of records at once I would be choosing Date::Calc instead and dealing with any necessary futzy bits manually.
On Thu, May 3, 2012 at 2:53 AM, Rick Measham <r...@measham.id.au> wrote: > 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" <jan...@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 >
