++ to using precomposed TZ object (as you observed, supplying only the
name as a string still results in lengthy DT:TZ object creation
overhead.)
If you use them, I would also precompose any necessary Formatter or
Locale objects.
Depending on how you're parsing the date strings and composing the DT
objects, `local $Params::Validate::NO_VALIDATION = 1;` can speed
things up for you.
If you're using a DateTime::Formatter class to parse strings into DT
objects for you, you might investigate using your own regex to chop up
the string and call DT->new directly.
This code (including comments) is from early 2011 and I unfortunately
do not have benchmark data handy:
# NOTE: This method is faster than using DateTime::Formatter::MySQL
# NOTE2: It's also faster than `split m#[ /:T-]#`
$timestamp =~ m!^
(?:\s+)?(\d{4,4})[/-](\d{1,2})[/-](\d{1,2}) # Required date portion
(?:[T\s](\d{1,2}):(\d{1,2}):(\d{1,2}))? # Optional time portion
(?:\s?([\w/\+:]+))? # Optional timezone
$!x;
my ($y, $m, $d, $hr, $min, $sec, $tz) = ($1, $2, $3, $4, $5, $6, $7);
On 4 May 2012 13:20, Philipp K. Janert <[email protected]> wrote:
> On Thursday 03 May 2012 02:14:45 you wrote:
>> > From: Philipp K. Janert [mailto:[email protected]]
>> > 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
