|Problems? Is your data what you think it is?|
(Shrug...) What can I say, Will? It may astound you that I would say ... “I don’t particularly care that “my code will run ‘way faster!’ ”
Really, the only thing that matters to me is that the software ... that is to say, the software that I have, and, that is to say, already ... produces the correct results, and that I can prove it.
Furthermore, the actual extent of compiler-induced measurable improvements to the runtime of any code whatsoever is, at this point in time, a remarkably slight delta. It is the stuff of “Whetstones” by now. To make significant improvements to any compute algorithm, you have to change the algorithm. Therefore, the usual actual business response is to “throw silicon at it (again),” thereby avoiding both the uncertainty and the expense of changing source, instead trusting Moore’s Law to once again save your business bacon. After all, a capital investment in a $30,000 souped-up piece of silicon is nothing compared to the unfathomable expense of touching “paid-for source code that works.”
The essence of your “commandments” is that “source-code change” is not only ‘free,’ it is ‘a Good Thing.™’ ” Most unfortunately, this is not the case. Aye, there’s the rub ...
“Source-code change” ... is not an option.
Think about it ... “why t’hell was Moose so successful, when it is a Wart on top of a Hack on top of a Bunion to try to make Perl-5 the object-oriented language that it never was, and never was intended to be?” The short answer was that you could use Moose; to put on your Super Suit, and-d-d-d... that you could utter no Moose; to take it off again. All of which enabled you to make Useful Improvements To™ “
In reply to Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments