Front page | perl.perl5.porters |
Postings from July 2010
2010/7/7 Jesse Vincent <jesse@fsck.com>: >> My biggest problem is the "creeping featuritis". >> Why must every new perl release be slower than the previous? >> I'd love to see some run-time hurting features being optional only. >> My concerns are worse startup-times (ENV magic, INC magic), >> HEK mallocs, and such. > > Features don't need to equate to decreased performance, though sometimes > (but not always) features _are_ worth a speed hit in some circumstances. > In general, yes, I would prefer that each release of Perl be faster and > more memory efficient than the previous one. > > Reini, I've seen you assert performance degradation with new features, > but I don't know of any reliable benchmarks of a variety of perl > versions on the same hardware+OS that we can use to quantify, visualize > and _stop_ performance regressions. Do you have such a test suite > and/or published numbers that other porters can use? Unfortunately not, since I'm porter and theorist only, since cygwin and unices in vm's cannot be trusted too much, and I would loose too much time waiting for those huge tests. My current full compiler test suite runs from 40min to 26 hours for all combinations if successful. But I get a lot of benchmarks and feedback from the real-world, which I try to analyse. 5.6 is still the fastest by far, all non-threaded of course, then 5.8.9, then 5.10, then 5.12. But some newer modules don't work with these old modules anymore. smoke-testers should really add some place for benchmarks and regressions for typical platforms and combinations. abe and tux are doing this alone now. I also like to see comparisons for llvm and more different compilers and different mallocs; dlmalloc, ptmalloc2 (glibc), ptmalloc3, tcmalloc, Hoard, nedmalloc, msvcrt, ... Should not be too hard to setup for a newbie. -- ReiniThread Previous | Thread Next