tconnors at astro.swin.edu.au
Sun Dec 9 17:20:28 PST 2007
On Mon, 10 Dec 2007, Toby Corkindale wrote:
> Tim Connors wrote:
> > I've got code that makes extensive use of DateTime::new via
> > DateTime->from_epoch() and
> > DateTime::Format::Strptime->parse_datetime()
Looks like it is actually in DateTime::new rather than any routines it
calls -- supplying -S to dprofpp shows:
DateTime::new x 548 11.99s = (11.71 + 0.28)s
DateTime::DefaultLocale x 548 0.00s
DateTime::Locale::load x 548 0.09s = (0.04 + 0.05)s
Params::Validate::_validate_pos x 548 0.05s
DateTime::TimeZone::new x 548 0.04s = (0.02 + 0.02)s
DateTime::TimeZone::UTC::new x 548 0.00s
Params::Validate::_validate x 548 0.02s
DateTime::_calc_local_rd x 548 0.01s = (0.00 + 0.02)s
DateTime::TimeZone::UTC::is_utc x 548 0.00s
DateTime::_calc_local_components x 548 0.02s = (0.02 + 0.00)s
DateTime::_rd2ymd x 548 0.00s
DateTime::_seconds_as_components x 548 0.00s
DateTime::_calc_utc_rd x 548 0.02s = (0.01 + 0.01)s
DateTime::TimeZone::UTC::is_utc x 548 0.01s
DateTime::_normalize_tai_seconds x 548 0.00s
DateTime::_handle_offset_modifier x 548 0.00s = (0.00 + 0.00)s
DateTime::TimeZone::is_floating x 548 0.00s
DateTime::_offset_for_local_datetime x 548 0.00s = (0.00 + 0.00)s
DateTime::TimeZone::UTC::offset_for_local_datetime x 548 0.00s
DateTime::_month_length x 548 0.00s = (0.00 + 0.00)s
DateTime::_is_leap_year x 548 0.00s
DateTime::_normalize_nanoseconds x 548 0.00s
DateTime::_time_as_seconds x 548 0.00s
DateTime::_ymd2rd x 548 0.00s
Params::Validate::_validate x 548 0.12s = (0.12 + 0.01)s
DateTime::__ANON__ x 2740 0.01s
ie, only of those 11.99s are due to subroutines.
Nice tool, dprofpp is :)
> > 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?
> Yep, that'd be the backported bugfix for the bless/overload issue that
> CentOS/RHEL has.
> Expect modules that use those heavily to take HUGE performance hits.
Gah, if I didn't already have enough reason to thouroughly dislike having
to use CentOS and RHEL instead of Debian, at work.
> Some Catalyst/DBIx::Class apps I wrote are almost unusable on those two
> distributions as a result :(
> You can roll your own vanilla Perl.. Or else Ubuntu/Debian/Gentoo seem
> to have non-borked Perl in their distros..
My google fu isn't working for me -- have you got a pointer to this bless
More information about the Melbourne-pm