[Melbourne-pm] DateTime::new
Tim Connors
tconnors at astro.swin.edu.au
Sun Dec 9 16:49:38 PST 2007
I've got code that makes extensive use of DateTime::new via
DateTime->from_epoch() and
DateTime::Format::Strptime->parse_datetime()
I've recently noticed a rather large regression in speed of these calls
(factors of many). I don't think it's the actual modules, since I hadn't
touched CPAN in quite some time, and I recall having upgraded my
distribution's perl in the past to version 5.8.8 I think (from somewhere
around 5.8.0), balking at the speed of these calls, downgrading back to
whereever it came from and seeing the speed go back to a good healthy
speed again.
However, looks like the distribution (centos 4 == redhat enterprise 4) has
forced an upgrade of perl to 5.8.8 this time, and I get the slow DateTime
calls again.
Would anyone have any idea as to what might have changed?
The results of dprofpp -u -p:
55.9 24.11 30.600 17409 0.0014 0.0018 DateTime::new
7.67 3.306 3.478 17908 0.0002 0.0002 Params::Validate::_validate
7.15 3.079 33.580 8686 0.0004 0.0039 DateTime::Format::Strptime::parse_
datetime
...
(and I believe the DateTime::new is coming almost exclusively from
DateTime::Format::Strptime::parse_datetime in this case, so it must be
initialising it twice for whatever reason)
I've tried with a floating timezone, UTC, GMT, local and they're all
equally slow.
I tried stepping through with perl -d, and it's not obvious yet to me
where the expensive calls are done (I need to work out how to tell DProf
to dig down into the calls DateTime makes). The most obvious location
would be Time::Local::timegm_nocheck, since everything prior to that is
just trivial manipulations of the supplied string.
Both versions of the following test out as quick:
DateTime 0.36 0.41 DROLSKY/DateTime-0.41.tar.gz
DateTime::Format::Strptime 1.0700 1.0702 RICKM/DateTime-Format-Strptime-1.0702.tgz
DateTime::Locale 0.34 0.35 DROLSKY/DateTime-Locale-0.35.tar.gz
DateTime::TimeZone 0.62 0.70 DROLSKY/DateTime-TimeZone-0.70.tar.gz
Any ideas of where to go from here?
--
Tim Connors
More information about the Melbourne-pm
mailing list