I can confirm this for the X86_64 version.  I Use Slim Devices' slimserver
(slimserver-6.2.2-1) runs somewhere 20 times faster when just switching between
versions perl-5.8.8-4 and perl-5.8.8-5 (and no other rpms are updated) with the
perl-5.8.8-5 version being the slower one.  Other perl related RPMs I have
installed:
perl-Digest-SHA1-2.11-1.2
perl-XML-Parser-2.34-6.1.2.2
perl-SGMLSpm-1.03ii-16.2
mod_perl-2.0.2-5.1
perl-Digest-HMAC-1.01-14.2
perl-BSD-Resource-1.24-3.2.2
newt-perl-1.08-9.2.1
perl-Compress-Zlib-1.41-1.2.2
perl-Net-DNS-0.57-1
perl-String-CRC32-1.4-1.FC5
perl-DBI-1.50-2.2
perl-Net-IP-1.24-2.2
perl-libwww-perl-5.805-1.1
perl-HTML-Parser-3.51-1.FC5
perl-DBD-MySQL-3.0004-1.FC5
perl-5.8.8-4
perl-URI-1.35-2.2
perl-HTML-Tagset-3.10-2.1

I am not a perl hacker (I do more in C++ and python), but I am more than willing
to provide any trace data that I could generate.

Created attachment 132469 [details]
Results of perlbench-0.93 when run for perl-5.8.8-5 and perl-5.8.8-4 on a dual processor i386 FC-5 machine

The attached perlbench log shows that the performance of perl-5.8.8-4 compared
to perl-5.8.8-5 is virtually identical for common perl operations . Perlbench
is a standard benchmark test for perl.

Yes, I have duplicated the severe performance loss when running the WebGUI
t/i18n/label.t test.

Reblessing overloaded objects now incurs a performance penalty in 5.8.8-5+ : 
this is due to the fix for perlbug #34925 'overload and rebless':
   http://rt.perl.org/rt3/Ticket/Display.html?id=34925
The fix for this bug (change 27512) involves a 'brute force approach' to 
detect overloaded objects that are then reblessed; the performance penalty
is proportional to the number of active scalars in the perl program.

Testing 5.8.8-5 compiled without the 'perl-5.8.8-U27512.patch' applied
shows no performance loss when running the WebGUI t/i118n/label.t test
over 5.8.8-4 - the 27512 patch is definitely the cause.

Perlbug 34925 severely affects the CPAN DBI::Class module.

As reblessing an overloaded object is quite rare, the brute force approach
was deemed acceptable by the upstream perl maintainers, who have applied this 
overload and rebless detection mechanism to the current maintenance release
of perl.

In the upstream 'blead' perl 5.9.4, a fix with no adverse performance impact
was applied (change # 27506), but this introduces binary incompatibilities 
which impact  mod_perl; one cannot apply this fix to the 5.8.x releases without

introducing major binary incompatibilities, and I've not been able to see
an alternative fix (in 5.8.8, every SV_f* flag bit is already used - in 
5.9.4, they've changed the meaning of the flag bits and reserved one 
to flag the case of overload and rebless).

So, I think we'll have to accept the performance tradeoff for correct 
operation in the presence of overload and rebless, until perl-5.9.x 
is released as the stable version of perl-5.

The real problem seems to be that patch 27512 breaks more than it fixes.  I
believe the patch itself is bugged; the brute force search seems to be
triggering in cases where it doesn't seem to be necessary.

I have a project internal to my employer that makes heavy use of the DateTime
module, which was significantly affected by this patch.  DateTime does overload
but not reblessing, but the search is still triggered (for no apparent reason)
whenever the ->clone method is called, even though there's no reason for it (a
completely new reference is created by ->clone, it does *not* rebless anything).

DBIx::Class is also bitten by this; see
http://forums.slimdevices.com/showpost.php?p=123372&postcount=20

Personally I think this patch needs more testing from upstream before it goes
into a stable line update to Fedora.

Reopened - assigning to me to keep an eye on this issue.

This shows up in RHEL5 also.

Would another bug be better, or ... overload this one  :)

perl-5.8.8-10 is 1000X slower! 
(It seems like O(2^n) slowdown where n is number of onmemory SV)
Please rethink. It can kill real apps. (Or Fedora/RedHat is not for Perl?)

# Here is simple benchmark, borrowed and modified from
# http://blog.yappo.jp/yappo/archives/000515.html

use Benchmark;
timethese(shift || 100000, {
'overload' => sub { push our @array, TestOverload->new },
'not overload' => sub { push our @array, TestNoverload->new },
});

package TestNoverload;
sub new { bless { hoge => 'hoge' }, shift }


package TestOverload;
use overload (
q{""} => sub {},
);
sub new { bless { hoge => 'hoge' }, shift }

FWIW, I just verified that perl-5.8.8-18.fc7 still has this problem, but a 
fresh compile of 5.9.4 doesn't.

It was not O(2^n) but O(n^2), sorry. See following plot(n=10000 .. 100000)

http://buribullet.net/svntrac/buribullet/attach_get/2/fedora-perl-overload.png

Of course this should be O(n). O(n^2) for this case is not acceptable overhead.

This is reported upstream here:

http://rt.perl.org/rt3/Public/Bug/Display.html?id=43283

And, as it turns out, Nicholas Clark points out a patch which fixes this issue
on my test system:

Benchmark: timing 100000 iterations of not overload, overload...
not overload:  1 wallclock secs ( 0.48 usr +  0.24 sys =  0.72 CPU) @
138888.89/s (n=100000)
  overload:  2 wallclock secs ( 0.50 usr +  0.22 sys =  0.72 CPU) @ 138888.89/s
(n=100000)

Building a fixed version for rawhide/f8 - updates for F7 and FC6 should be
available soon.

Thank you for your quick action!
It will save both community of Perl and Fedora/RedHat.

Update - I'm having a little trouble building the new perl - I'm still working
on it, though.

> a little trouble...

If it is so hard, simply removing U27512 & U27509 will be
good enough for most of Perl users, IMHO.

# Following patch is borrowed from http://femo.jp/kazeburo/br51s0s3qh

diff -u -r1.1 perl.spec
--- perl.spec   1 Jul 2007 01:47:23 -0000       1.1
+++ perl.spec   1 Jul 2007 01:50:05 -0000
@@ -5,7 +5,7 @@
 %define multilib_64_archs x86_64 s390x ppc64 sparc64

 %define perlver    5.8.8
-%define perlrel    10
+%define perlrel    11
 %define perlepoch  4

 %{?!perl_debugging:    %define perl_debugging 0}
@@ -160,8 +160,8 @@
 Patch27116:    perl-5.8.8-U27116.patch
 Patch27391:     perl-5.8.8-U27391.patch
 Patch27426:    perl-5.8.8-U27426.patch
-Patch27509:     perl-5.8.8-U27509.patch
-Patch27512:     perl-5.8.8-U27512.patch
+#Patch27509:     perl-5.8.8-U27509.patch
+#Patch27512:     perl-5.8.8-U27512.patch
 Patch27604:     perl-5.8.8-U27604.patch
 Patch27605:     perl-5.8.8-U27605.patch
 Patch27914:     perl-5.8.8-U27914.patch
@@ -367,9 +367,9 @@

 %patch27426 -p1

-%patch27509 -p1
+#%patch27509 -p1

-%patch27512 -p1
+#%patch27512 -p1

 %patch27604 -p1

This should be fixed in the latest perl in F8/rawhide: perl-5.8.8-22.fc8 or later

According to the changelog, 4:5.8.8-19 for -fc7 solves this bug, but the latest
4:5.8.8-27 still gives this warning:

WARNING: DBIx::Class::StartupCheck: This version of Perl is likely to exhibit
extremely slow performance for certain critical operations.
Please consider recompiling Perl.  For more information, see
https://bugzilla.redhat.com/show_bug.cgi?id=196836 and/or
http://lists.scsys.co.uk/pipermail/dbix-class/2007-October/005119.html.
You can suppress this message by setting DBIC_NO_WARN_BAD_PERL=1 in your
environment.

Any ideas?

Following through that thread, and looking at the source of DBIC::StartupCheck,
it appears that it's more of a "MAY" than definite, and that DBIC::StartupClass
doesn't know how to check to see if the particular patches have been applied. 
(AFAICT at least.)

I have DBIx::Class up for review (bug perl-DBIx-Class); if we can verify that
indeed Fedora perl has the correct fixes in place (which it does sound like it
does) then hopefully we can:

1. override DBIC::StartupCheck's logic in Fedora's packages, until #2
2. create and funnel logic upstream that accurately figures out if this has been
applied... Note that this needs to be a near no-op, as these checks are run
everytime DBIC is use'd.