Re: Why "Modern Perl" is slower than "Legacy Perl"?

Well that sounds very nice, but during my recent encounter with DBD::SQLite I got a new question: is the move worth it? I don't mind all the syntactic sugar - it's all very fine but even Perl 5.005 had it more than enough for me to study and master for another ten years.

You seem to reduce the changes between perl 5.8 and 5.14 to two categories: speed and syntactic sugar.

But there are lots of other changes between those versions, which IMHO make the upgrade very worthwhile, even if it comes with a slight speed penalty. If you upgrade from 5.8 to 5.14, you get for example:

A module installer that actually works most of the time
Lots of bug fixes
Support
The capability to install many modules. Quite a few of the modules that don't depend on 5.10 or newer directly do (often indirectly) depend on newer versions of core modules, and upgrading core modules has always been a delicate business.
A regex engine that doesn't segfault when you provide it with too long strings
Greatly improved Unicode handling
Unicode handling in the Pod tools
Warnings in the case of undefined behavior (for example my in statement-modifying conditionals)
Trie regex optimizations that speed up alternatives of literal strings by a big amount

Plus lots of features that you probably discount as "syntactic sugar".

That said, I'd be interested in a performance comparison for some real-world applications that not only loop over arrays and assign undef to some elements, but do some more interesting stuff, like matching non-trivial regexes, doing IO with IO layers, index into Unicode strings and so on.

Perl 6 - second systems done right

Comment on Re: Why "Modern Perl" is slower than "Legacy Perl"?

Replies are listed 'Best First'.
Re^2: Why "Modern Perl" is slower than "Legacy Perl"? by dwalin (Monk) on Jun 20, 2011 at 10:43 UTC
You make it sound like "syntactic sugar" is an insult, which it isn't. I wasn't going Luddite, I was merely pointing out that "Modern Perl" comes with a price tag; it can be quite hefty for some applications and may be worth additional consideration. You're arguing the software developer side of equation, and of quite advanced hacker, too. I agree that new features can make a developer more productive, but what I'm saying is that it's not given. How many people out there are using this interesting stuff in their day-to-day work? I don't, so I can't run a performance comparison for it. I ran tests for what I do use, and it shows me that even with the latest Perl release my DBD::SQLite application shows 17% performance hit compared to 5.8.9. Does that matter? For me, it does a lot. As for your examples, I don't see anything ground-shaking there. Module installer was there for ages, CPAN.pm is working fine for me thanks. Support I have never needed, and if I need security I will buy commercial support anyway. Lots of bug fixes were supposedly backported to 5.8.9 which was released after 5.10 - and how many of later fixes are for later bugs? Unicode is one major advantage, sure, but I don't need it, usually - and considering tchrist's latest musings on stackoverflow, I'd screw it up anyway. So, do I really gain something visible with Modern Perl? Yeah, performance hit. All new features are potential good, but slower execution is here for every existing script and module, every time I run them. Are you ready to dismiss this easily in favor of newer features? I don't. In short, I don't think that "Modern Perl is better for everyone" is true. That said, I do wish for a magical combination of Modern Perl features and Legacy Perl speed... Regards, Alex.	[reply]
Re^3: Why "Modern Perl" is slower than "Legacy Perl"? by Tux (Canon) on Jun 20, 2011 at 11:52 UTC
More recent Unicode support int perl-5.14.x is for me the reason to have it already support. I can now do things that I was unable to to till now and also was unable to patch in previous versions. I fully agree that the "upgrade" is no upgrade to every single user, but with the current policy of more frequent releases, the number of fixes that are accepted to previous releases has considerably dropped. The chance on an update for 5.8.9 is close to zero, and I also would not wait for an update on 5.10.1. If such an update would be released at all, my bet would be that the only updates would involve being able to build on modern C compilers and maybe a fix for a CVE if such is available. No doc fixes, not added features. There have been a huge number of bug-fixes and improvements in the regular expression engine. If your script does not use regular expressions, you won't ever see that. What I like in "Modern Perl" is that regular expressions now offer me more and more a way to express my mind in that expression. The new `\K` and `(?\|)` might be small changes, but they both simplify my code and make it easier to proceed. Also note that with these constructs, you need less "other" statements in your code to do what you want. The performance gain might thus not be in the expression itself, as well as in the not needing other statements after the regex. Also note that modern builds might take some options for the most recent C compilers to take advantage of newer optimization levels. Even if the language itself might have suffered a slowdown in your favorite syntax, the binary might still be faster. Also you should consider the more recent architecture. If you are moving from a 32bit OS to a 64bit OS, it might not (only) be the language that shows the slowdown. The interaction with memory management or maybe even emulation layers might have a huge impact on performance. If performance is really critical, try to build the versions you are comparing from scratch. Both on the same machine and both with the same build/configure options and then compare again. You might be surprised (or you might not, YMMV). As a last note, you are testing with DBD::SQLite. Did you check if the slowdown is in one of the involved modules? DBI, DBD::SQLite also evolve over time, and the modules that are released on CPAN quite often not only fix bugs, but also try to take care of acting as desired for different versions of perl. When comparing, please use the same version of all modules that are used. (when possible) As you saw in a previous post from me, I have an external disk with about 85 versions of perl. They are all built under the same conditions with the same configuration (where possible: threads vs non-threads is of course a big deal). This way, I can prove to myself that there is a reproducible performance difference between versions. And then still, I can only prove it for that architecture. IA64 != x86_64. Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]