I'm currently loading some new servers with CentOS6 on which perl5.10 is the standard version of perl provided. However, I've also loaded perl5.18 and I don't think the version of perl is significant in the results I'm seeing. Basically, I'm seeing perl performance significantly slower on my new systems than on my 6 year old systems.
Here's some of the relevant details: + 6 year old server, 32 bit architecture, CentOS5 perl5.8 perl, and in particular regexp operations, perform reasonably fast. + Very new server, 64 bit architecture, CentOS6, perl5.10 (and have tried perl5.18) perl, and in particular regexp operations, perform significantly slower than on the 6 year old server. That struck me as odd right off. I though surely, perl running on a modern high-end cpu is going to beat out my code running on 6 year old hardware. I've compared CPU models at various CPU benchmarking sites and the new CPUs, as you would expect, are ranked significantly higher in performance than the old. I've also installed perl5.8 on the new 64bit servers and the performance is similar to that of perl5.10 and perl5.18 on the same 64bit servers. Given that, I don't think perl version plays a significant factor is the performance diffs. Is it an accepted fact that perl performance takes a hit on 64 bit architecture? I've tried comparing some of the perl -V and Config.pm results looking for significant differences. That output is pretty verbose and the most significant difference is the architecture. I could provide some of my benchmarking code if that would be of help. The differences are significant. The only reason I'm looking at this is because I could see right off that some of my code is taking 30-40% longer to run in the new environment. Once I started putting in some timing with Time::HiRes I could see the delay involved large amounts of regexp processing. Right now, I'm just looking for any opinions on what I'm seeing so that I know the architecture is the significant factor in the performance degradation and then consider any recommendations for improvements. I'm happy to provide further relevant details. Thanks, Phil