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.

If all you saw was the "fistfight", you missed the important bits.

But if that and the other existing threads aren't sufficient to convince you that offering Readonly to novices as a template is not a good idea, then perhaps avoiding a 40x performance penalty will?:

#! perl -slw
use strict;
use Benchmark qw[ cmpthese ];

use constant {
    TRUE => 1,
    FALSE => 0,
    VALUE => 12345,
};

use Readonly;

Readonly::Scalar my $true => 1;
Readonly::Scalar my $false => 0;
Readonly::Scalar my $value => 12345;


sub usingConstant {
    for( 1 .. 1e6 ) {
        if( TRUE ) {
            my $sum = VALUE * VALUE;
        }
        elsif( FALSE ) {
            ;## Never called
        }
    }
}

sub usingReadonly {
    for( 1 .. 1e6 ) {
        if( $true ) {
            my $sum = $value * $value;
        }
        elsif( $false ) {
            ;## Never called
        }
    }
}

cmpthese -1, {
    const    => sub{ usingConstant() },
    Readonly => sub{ usingReadonly() },
};

__END__
c:\test>ROvCONST.pl

         s/iter Readonly    const
Readonly   5.66       --     -98%
const     0.141    3931%       --
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

Unannounced update. Pathetic, "performance doesn't matter" missive.

Now I must crush you.

Fail!

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.

<Reveal this spoiler or all spoilers in this node or all in this thread>

Fail!

except that this imposes no performance penalty over a simple my() declaration:

Fail! Note that constant is actually faster than literals:

<Reveal this spoiler>

c:\test>ROvCONST.pl
           Rate Readonly literals    const
Readonly 4.06/s       --     -44%     -49%
literals 7.21/s      78%       --      -9%
const    7.90/s      95%      10%       --
[download]

In fact, I have slowly come to define most of my variables as scalars -- scalar hashrefs, scalar arrayrefs -- rather than hashes and arrays.

Fail!

Look up who said "Programs are more readable if different things look different.". And when. And why.

Or buy|rent a faster box, which might well be a cheaper solution than wasting my time.

Fail!

Take a look around you. In the early noughties, that attitude flew because clockspeeds increased from 400 MHz (1999) through to 3.3GHz in 2003. But it has stagnated for the last 7 years. Sure, they're managing to get through more instructions per clock, but only if the pipelines don't stall.

Throwing faster hardware at self-induced performance issues is no longer an option. Now, the options are threading, clustering, or map-reduce. All of which are far more complicated than simply avoiding, avoidable premature pessimisations

Let's discuss another aspect of the node.

Nothing else in the node was even vaguely of interest to me me. Nor anyone else it seems.

My play scripts generally exercise at most a dozen lines of code and exit almost before I touch Enter.

All that O'Woe(*) to try out a "dozen lines of code"?

(*)Order of Worshipful over-engineers.

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 could send me a /msg. Or better, you could simply follow the conventions of the forum you are using--that have served the Monastery perfectly well for almost a decade--and post replies as replies, rather than as cowardly, secret updates to your own nodes.

You are crushed.

Oooh. I'm sooo crushed. Woe isth me.

The benchmarks you published showing an improvement of nearly 4000% were either cooked

So, you're calling me a liar? I published my benchmark code so the results posted can be verified.

I'm not going to lecture the Monastery on the significance of these results.I post three sets of results so you can judge for yourself the consistency of my experimental method.

How can we "judge" anything about your benchmarks when you are too cowardly to publish the code.

For the rest of your diatribe...words fail me.

Tip: Before you set about educating others, it is better if you have some understanding of your subject.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP an inspiration; A true Folk's Guy

I have nothing more to say on this topic. But I cannot refuse a reasonable request to publish my method of obtaining results.

Code follows. I ran the script on my MPC TransPort X3100, an obsolete laptop upgraded with a Pentium (R) M, with 2 Gb memory. Continued operation at top speed quickly overheats the chip, so I fixed the CPU frequency during these tests to 1.60 GHz. Interpreter version is 'v5.10.1 (*) built for i686-linux-thread-multi'. OS is Ubuntu 9.10, Linux 2.6.31-19-generic. I did my best to idle other tasks while benchmarking but I did not shut down X.

In the script, I bypass the ::XS enhancement with declarations of the form:

Readonly         my $n_true => 1;
[download]

... instead of the correct:

Readonly::Scalar my $r_true => 1;
[download]

While I admit to some doubt as to why ::XS applies to one set of declarations and not the other; and have some small feeling that I would prefer to compare performance with ::XS loaded against that when it is completely not loaded; I'm confident that the usingNo_XS() routine reasonably reflects performance when ::XS is not available.

I noted earlier that you obtained the performance expected without ::XS even using the correct syntax; and therefore, you likely did not have Readonly::XS installed. You replied with, among other stuff, what looked very much like an effort to install it, whereupon your performance improved significantly, as expected. I don't understand why you're not pleased.

I cannot imagine personally fighting a pitched, cross-thread battle over a 2x difference in performance. I can imagine someone else doing so over a 40x difference, which results you showed previously (and which I preserve below). I do not, Sir, call you a liar. I merely fail to replicate your results.

You are /msg-ed.

#! /run/bin/perl
#~ use strict;
use warnings;

use Benchmark qw[ cmpthese ];

use constant {
    C_TRUE => 1,
    C_FALSE => 0,
    C_VALUE => 12345,
};

use Readonly;

# Correct...
Readonly::Scalar my $r_true => 1;
Readonly::Scalar my $r_false => 0;
Readonly::Scalar my $r_value => 12345;

# Much slower...
Readonly my $n_true => 1;
Readonly my $n_false => 0;
Readonly my $n_value => 12345;

# My...
my $m_true = 1;
my $m_false = 0;
my $m_value = 12345;

# Package variables...
$p_true = 1;
$p_false = 0;
$p_value = 12345;


sub usingConstant {
    for( 1 .. 1e6 ) {
        if( C_TRUE ) {
            my $sum = C_VALUE * C_VALUE;
        }
        elsif( C_FALSE ) {
            ;## Never called
        }
    }
}

sub usingReadonly {
    for( 1 .. 1e6 ) {
        if( $r_true ) {
            my $sum = $r_value * $r_value;
        }
        elsif( $r_false ) {
            ;## Never called
        }
    }
}

sub usingNo_XS {
    for( 1 .. 1e6 ) {
        if( $n_true ) {
            my $sum = $n_value * $n_value;
        }
        elsif( $n_false ) {
            ;## Never called
        }
    }
}

sub usingPackage {
    for( 1 .. 1e6 ) {
        if( $p_true ) {
            my $sum = $p_value * $p_value;
        }
        elsif( $p_false ) {
            ;## Never called
        }
    }
}

sub usingMy {
    for( 1 .. 1e6 ) {
        if( $m_true ) {
            my $sum = $m_value * $m_value;
        }
        elsif( $m_false ) {
            ;## Never called
        }
    }
}

sub usingLiterals {
    for( 1 .. 1e6 ) {
        if( 1 ) {
            my $sum = 12345 * 12345;
        }
        if( 0 ) {
            ;## Never called
        }
    }
}

cmpthese -20, {
    const       => sub{ usingConstant() },
    Readonly    => sub{ usingReadonly() },
    My          => sub{ usingMy() },
    literals    => sub{ usingLiterals() },
    package     => sub{ usingPackage() },
    No_XS       => sub{ usingNo_XS() },
};

__END__
c:\test>ROvCONST.pl

         s/iter Readonly    const
Readonly   5.66       --     -98%
const     0.141    3931%       --


(including No_XS; 1.60 GHz fixed)
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]

Note: Contents may change.