3 ms·

Does anyone have the numbers to go with the claim that Perl is faster than Python?

Kototama 12y ago
Maybe here http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=perl&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... But basically they seem to be both in the same category.
SwellJoe 12y ago
For fun, many years ago, I did a series of benchmarks of ack vs grin (both are programmers greps, one in Perl the other in Python, and both were written and maintained by excellent developers well-known in their respective languages). Because the tools do almost identical work, and can be configured to behave nearly identically, in terms of enabled features, types of searching to do, etc. I believe it's a useful real world performance test. At the time, ack (in Perl) ran in roughly a tenth the time of grin (in Python) on most tests. Similarly, find+grep with the right options (and occasionally run through sed or awk to get further refined results) was approximately an order of magnitude faster than ack (but was much harder to use, and so ack or grin were still preferable tools). It would likely be useful to repeat the experiment with modern Perl and Python versions. Both have improved and likely have better performance. It seems likely Python will have closed the performance gap some in the ensuing years. It's also worth keeping in mind that this may be a sweet spot for Perl, given its genesis as a language processing language. And, it may be a tough one for Python given its historic aversion to regular expressions as a common solution to problems. So, saying Perl is (or was) ten times faster for this class of problem may simply mean this is a problem that Perl is particularly good at, and may not cover other classes of problem. I'm suspicious of microbenchmarks, though enough microbenchmarks can give some sort of indication of what larger programs will do. But, they may also be indicative of the quality of the programmer contributing solutions...a better algorithm implementation can often erase language differences. Which is why I liked comparing two nearly identical programs, both by known excellent developers and not doing anything particularly prone to algorithmic complexity, as a means of testing language performance. I imagine one could find other examples that would be good to compare. scons and cons, perhaps, would be another decent choice, assuming cons is still actively maintained.

Maybe here http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=perl&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... But basically they seem to be both in the same category.

SwellJoe 12y ago

For fun, many years ago, I did a series of benchmarks of ack vs grin (both are programmers greps, one in Perl the other in Python, and both were written and maintained by excellent developers well-known in their respective languages). Because the tools do almost identical work, and can be configured to behave nearly identically, in terms of enabled features, types of searching to do, etc. I believe it's a useful real world performance test. At the time, ack (in Perl) ran in roughly a tenth the time of grin (in Python) on most tests. Similarly, find+grep with the right options (and occasionally run through sed or awk to get further refined results) was approximately an order of magnitude faster than ack (but was much harder to use, and so ack or grin were still preferable tools). It would likely be useful to repeat the experiment with modern Perl and Python versions. Both have improved and likely have better performance. It seems likely Python will have closed the performance gap some in the ensuing years. It's also worth keeping in mind that this may be a sweet spot for Perl, given its genesis as a language processing language. And, it may be a tough one for Python given its historic aversion to regular expressions as a common solution to problems. So, saying Perl is (or was) ten times faster for this class of problem may simply mean this is a problem that Perl is particularly good at, and may not cover other classes of problem. I'm suspicious of microbenchmarks, though enough microbenchmarks can give some sort of indication of what larger programs will do. But, they may also be indicative of the quality of the programmer contributing solutions...a better algorithm implementation can often erase language differences. Which is why I liked comparing two nearly identical programs, both by known excellent developers and not doing anything particularly prone to algorithmic complexity, as a means of testing language performance. I imagine one could find other examples that would be good to compare. scons and cons, perhaps, would be another decent choice, assuming cons is still actively maintained.