Front page | perl.datetime |
Postings from May 2012
Re: DateTime performance
Thread Previous
|
Thread Next
From:
Philipp K. Janert
Date:
May 4, 2012 07:26
Subject:
Re: DateTime performance
Message ID:
201205032120.38488.janert@ieee.org
On Thursday 03 May 2012 02:14:45 you wrote:
> > From: Philipp K. Janert [mailto:janert@ieee.org]
> > Sent: Wednesday, 2 May 2012 8:29 AM
> >
> > Question:
> >
> > When using DateTime for a large number of
> > instances, it becomes a serious performance
> > drag.
>
> ...
>
> > 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.)
>
> Hi Phillip,
>
> My #1 tip is to pre-prepare/cache the DateTime::TimeZone object and pass it
> in to each creation of a DateTime object (via whatever mechanism you're
> using to do that). I have seen a case where we were using time_zone =>
> 'local' in a reasonably tight datetime object creation loop and saw
> significant speed increases just by cutting out that chunk of processing.
>
> In hindsight that was a silly thing to do but it became an easy win :-)
>
> I apologise if this is what you meant by supplying a time_zone explicitly
> in your comment above.
I have tried to specify the timezone explicitly as a string:
$dt = DateTime->new( ..., time_zone => "America/Chicago" )
which does not seem to help, but I have not tried to do:
$tz = DateTime::TimeZone( 'America/Chicago' )
$dt = DateTime->new( ..., time_zone => $tz )
I'll try that the next time I have to process one of my data
sets again. ;-)
Thanks for the hint.
>
> I can't recommend using a tool like NYTProf highly enough on a run of your
> tool to spot the low hanging fruit. See
> https://metacpan.org/module/Devel::NYTProf
>
> Cheers,
>
> Andrew
Thread Previous
|
Thread Next