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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]