RH EL 5 perl interpreter bug?

Ok, so I have a contract where I do some perl work. I've been coding away very hard on building a new version of an internal app for my client, and the new work leverages Catalyst. The work has been going very well, and Catalyst is a lot of fun to use. I've also been using Moose, and that has been real fun. So we reach a milestone and I test out our code on the dev integration server, and I start seeing funny, troubling results. My code seems to be performing 20-30 times slower on a machine that should be much faster than my local, aging MacBook Core Duo. What the heck?

Database? No. Memory? Don't think so. Object allocation? Err. That's not good. Could it be Moose? Oh, please no—my whole system is leveraging Moosey-goodness. So I put together some unit tests (if you don't use unit tests in your development process, you are insane), where I'm instantiating/allocating a lot of hash references, some blessed hash references (regular, ole Perl-OO), some vanilla Moose objects, and then my troublesome classes. Low and behold it wasn't Moose at all. It was overload. Whenever I instantiated my base class for my object sytem (which used overload), everything crawled to horribly slow speeds. 60% of the time gets spent in the "new" method, despite nothing really going on in there.

I hack up another unit test where I'm just using plain, vanilla Perl-OO via blessed hash references, and sure enough the class with overload takes forever to instantiate on the dev server. It runs just fine on my MacBook. Now I'm getting suspicious.

I went to the #moose IRC channel, and someone brought up that Red Hat stock perl interpreters are rumored to have issues with overload. So I downloaded the source for perl 5.8.8 (to match the version used in the Red Hat perl RPM) and I built it using the same options—I just installed it to ~/perl instead of to the system at large.

Sure enough, the unit test runs just like it does on my MacBook using the built-from-source perl interpeter (there was less than a 1% difference between the class with overload and the class without). I then re-ran the test with the stock interpreter from Red Hat and the stock interpreter took 300 times as long to instantiate the same amount of objects. You can see my test results here.

Off to bugzilla to get Red Hat involved. Hopefully it won't take too long to get a patch. At the worst, we can use an interpreter built from source until RH issues a fix.