[Melbourne-pm] DateTime::new

Tim Connors 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 
issue?

-- 
Tim Connors



More information about the Melbourne-pm mailing list