[Melbourne-pm] DateTime::new

[Toby Corkindale]

Tim Connors wrote:
> 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:
[snip]
> 
> ie, only of those 11.99s are due to subroutines.
> 
> Nice tool, dprofpp is :)

It's possible it's unrelated, although you mentioned that 'grading perl
fixed the problem, so I was thinking it'd be in the interpreter, and
wasn't thinking of the modules that are included too might have changed..

Since there's some interest, I've included more info on the patch issue
below.

>>> 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?

I have more details archived at home, but I think this was the one:
https://bugzilla.redhat.com/show_bug.cgi?id=253728
which was related to:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=34925

Looks like it's been solved on recent Fedora versions, at least.

Try out this test on a few systems:

-------cut to overloadtest.pl---------
#!/usr/bin/perl
use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
    $h{$i} = bless [ ] => 'main';
    print STDERR '.' if $i % 1000 == 0;
}
------------------------------------
Then run:
time ./overloadtest.pl

You'll notice an order of magnitude difference.
For comparisons sake, these are values from a couple of machines with
good Perl interpreters, one is quite recent and fast, the other is a few
years old. If you get results like half a minute, on a machine that's
not antique, then you should think about moving away from those RPMs :)

[modern machine]$ time ./overloadtest.pl
..................................................
real    0m0.112s
user    0m0.088s
sys     0m0.020s

[old machine]$ time ./overload.pl
..................................................
real    0m0.192s
user    0m0.180s
sys     0m0.000s

Toby

-- 
Toby Corkindale
Software developer