Well, I see your comment in the middle of a bloody fistfight over the relative merits of Readonly and constant. You'll excuse me if I don't feel the need to take up arms afresh.

There's a long list of modules in my play template. There are far more in my private canonical module invocation file. But no point of this node is to push a particular selection of modules. Rather, I suggest that beginners choose well from common modules, write their favorite invocations into their own play templates, and use them instead of rolling all their own routines.

TMTOWTDI and in some ways, the play template I show here isn't even one of them. It's a starting point from which, perhaps, a novice can begin to write a what-if script that others can understand.

2010-08-03:

I saw more than the fistfight that went to indent level 11; and no, I didn't miss any important bits. There were very few of them. Then I tried to get you to worry about something else. You're obsessed with a non-issue. I really wanted you to move on but you have managed to kill my node, well-written with considerable effort. Now I must crush you.

I'd guess, by looking at your command line invocation (c:\test>ROvCONST.pl), that you suffer under the burden of some flavor of Windows for which Readonly::XS is not available or is difficult to install. If I bypass ::XS on my own Ubuntu machine, I get performance similar to yours. So don't do that.

Readonly should not be used on hashes or arrays, or on scalars without the ::XS, unless performance is of no concern whatsoever, which is usually the case.

I'd be tempted to advise the power developer to avoid Readonly entirely, even for scalars with ::XS installed; except that this imposes no performance penalty over a simple my() declaration:

           Rate       My Readonly    const
My       3.23/s       --      -0%     -41%
Readonly 3.23/s       0%       --     -41%
const    5.46/s      69%      69%       --
[download]

Of course, this test is highly artificial, designed to stress a single feature to the breaking point. Shame on you; it doesn't break.

Personally, I rarely have the slightest interest in performance. My play scripts generally exercise at most a dozen lines of code and exit almost before I touch <Enter>.

We've come a long way since the Bad Old Days when we counted every bit and clock cycle. Back when, we didn't use Perl! If ever again I have a real concern about speed, I will not use a fancy, very high level, postmodern, interpreted scripting language. I'll try C, then assembler; and if I don't like the resulting hex, I'll patch it until I do. There was a time when I enjoyed that.

Now, not so much. Now, if I run into a performance issue, I'll benchmark the suspects and fix whatever is keeping the train in the station. Or buy|rent a faster box, which might well be a cheaper solution than wasting my time.

We are the masters. They are the slaves.

Human time is more valuable than computer time.

There has always been a countercurrent of industry insiders who, by virtue of their superior competency, are able to do more with less, and loudly demand that others do the same. We must resist this anti-trend. We need to keep moving in the right direction. We can always go back to wiring the computer up for each job; we will get very fast execution on small, slow machines. Or we can continue building larger, faster, better machines that allow us to use them more easily. This is Good.

You wrote: "...my constants don't look like variables." At least this isn't just more machine worship. It's actually a concern raised about code clarity, which does interest me.

But I don't agree with you. Almost anything can be stuffed into a scalar variable, which is a container or label, not the thing it contains. I keep this in mind when reading code; I look to see where an identifier is declared, where its contents are modified, and where it is documented; before I think I know what's inside of it. I don't rely on the funny doohickies. In fact, I have slowly come to define most of my variables as scalars -- scalar hashrefs, scalar arrayrefs -- rather than hashes and arrays. (I find this cuts down on later rewrites.) I avoid bareword filehandles; I don't warm to bareword read-only variables. In each case, I'm willing to let a clear choice of variable name tell as much of the story as can be told in a single token. If it works for you, then upcase your read-only $VAR. Or go ahead and use constant. Just don't pick a fight over it, please.

Meanwhile, I have been, for the last couple days, absolutely steaming over the implications of If all you saw was the "fistfight", you missed the important bits. coming from someone who has nothing to say about anything past the third executable line of Perl in my template. This despite my polite reply, my slightly less polite reply, and my rigidly correct request:

Let's discuss another aspect of the node.

2010-08-04:

"Unannounced update"? Where would you have me announce it? Or are we just playing forum chicken to see who will hit the right edge of the page first?

You are crushed. The benchmarks you published showing an improvement of nearly 4000% were either cooked or, I'm more sure, produced without benefit of Readonly::XS. Now, you publish a different set of benchmarks which confirm that constant is not even twice as fast as Readonly, properly used.

You ducked entirely my showing that Readonly performance, at least on my machine, is essentially identical to my() performance. Even if you're right, ducking the other guy's telling results makes you look wrong.

I hope we all understand why we don't scatter literals throughout our code. Just for fun, though, I added your new straw man to my script. For even more fun, I commented out use strict so I could test on plain old package variables:

No_XS    0.159/s       --     -94%     -94%     -94%     -96%     -97%
My        2.76/s    1638%       --      -1%      -3%     -36%     -40%
Readonly  2.79/s    1661%       1%       --      -2%     -35%     -39%
package   2.86/s    1700%       4%       2%       --     -34%     -38%
literals  4.33/s    2630%      57%      55%      52%       --      -6%
const     4.60/s    2796%      67%      64%      61%       6%       --

            Rate    No_XS Readonly       My  package literals    const
No_XS    0.161/s       --     -94%     -94%     -95%     -96%     -97%
Readonly  2.76/s    1619%       --      -2%      -8%     -37%     -42%
My        2.82/s    1659%       2%       --      -6%     -35%     -40%
package   2.99/s    1764%       8%       6%       --     -31%     -37%
literals  4.36/s    2618%      58%      55%      46%       --      -8%
const     4.73/s    2847%      71%      68%      58%       8%       --

            Rate    No_XS Readonly       My  package literals    const
No_XS    0.158/s       --     -94%     -94%     -95%     -96%     -97%
Readonly  2.80/s    1666%       --      -2%      -6%     -37%     -41%
My        2.85/s    1697%       2%       --      -5%     -36%     -40%
package   2.99/s    1785%       7%       5%       --     -33%     -37%
literals  4.47/s    2723%      60%      57%      50%       --      -5%
const     4.73/s    2885%      69%      66%      58%       6%       --
[download]

I'm not going to lecture the Monastery on the significance of these results. I'll tell you that this shows naively-used Readonly runs very slowly, enough to alarm someone into launching a jihad. Readonly::Scalar my() with Readonly::XS installed is neck-and-neck with plain my() and if you're going to dissuade us from one (based on benchmarks) you may as well rant against the other. I post three sets of results so you can judge for yourself the consistency of my experimental method.

Some think it's acceptable to publish misleading statements, then retract them when they're caught. You might do this now and win some support.

"Programs are more readable if different things look different." They're also more readable, and more maintainable, if similar things look similar. An element of a hashref, itself a hashref, is... a hashref. There are times to use a plain old hash, too. I'm finding broader applications of references than I did at first, when I resisted them mightily. Now, I'm not confused by %$zoo or $zoo->{$house}.

I don't actually know if throwing more, bigger, faster hardware at a slow script still works. It's simply not an issue for me. I doubt it will be, for simple what-if exercises or even for unit testing. I know performance issues may surface in large, complex applications running on small, lightweight machines. When and if I hit such an issue again, I'll fix it. Very likely, if some inner-loop performance is an issue, I will tackle it with a different tackle box. Until then, I plan to enjoy wasteful, amusing, flexible, maintainable Perl, with all the wheels on -- which actually runs super fast anyway, for some value of "super fast".

No other aspect of the OP interested you because you got stuck on line 11. Nobody else is interested because they see this unsightly mess and run away screaming. Millions of electrons were slaughtered in this battle. Let's not be the cause of any more broken-hearted hadrons.

Now, I suggest you go ahead and put your coherent, complete, well-reasoned arguments for constant all together in your own new node. I may come along and destroy them but it's unlikely. I promise not to hijack your node to promote another brand of breakfast cereal.

I'm done.