Sure, the (generally compile-time) checks that strict.pm invokes have to take some time. But the types of coding practices it discourages take more time at run-time. (Yes, it is faster to access a lexical variable than a global.) So it is hard to say which way the fraction of the second is going to go.

However there is no question that on any significant script you will save development time with strict.pm. And there is also no question that as a developer it is very important to come to understand that premature optimization is bad. So the question of how strict.pm plays out performance-wise is irrelevant to me, and should be irrelevant to any decent Perl programmer. The difference is small, it speeds development, and it assists in writing correct programs.

That is more than enough reasons to use it.

I totally agree that leaving out use strict for the sake of speed is a bad thing(tm) and would never actually commit such a blasphemy myself. I merely wonder for the sake of furthering my Perl knowledge, and hoped to make the point you can always get a bit more speed if you're feeling a little mad. Leaving out use strict is about as useful as loop flattening and infinitely more dangerous (said ominously). Sorry if I've given anyone bad ideas, and yes, 'the voices' are generally wrong.
HTH

broquaint

Avoiding strict refs for speed? Ack! Pttht!

A quick walk thorugh the source reveals that way down in the bowels of op.c, Perl_ck_rvconst is the function checking strict 'refs'. The section reads:

if ((PL_hints & HINT_STRICT_REFS)&&(kid->op_private & OPpCONST_BARE)){
            char *badthing = Nullch;
            switch (o->op_type) {
            case OP_RV2SV:
                badthing = "a SCALAR";
                break;
            case OP_RV2AV:
                badthing = "an ARRAY";
                break;
            case OP_RV2HV:
                badthing = "a HASH";
                break;
            }
            if (badthing)
                Perl_croak(aTHX_
          "Can't use bareword (\"%s\") as %s ref while \"strict refs\"
+ in use",
                      name, badthing);
        }
[download]

Next, we've got a switch statement with three possibilities: we wanted a SCALAR, ARRAY or HASH reference. That'll compile down to something tight and small (three comparisons, a jump-table of some kind, etc...). Only if any of these match does badthing get set and the error thrown.

So at the very worst case that doesn't actually throw an error you've got:

• A bit-AND you'd have to do anyway.
• A C pointer deref and another bit-AND
• Up to three additional comparison operations
• Moving a pointer
• And a dereference of one more pointer.

So if you're worried about a small number of ANDs, pointer moving and comparisons to check for strict because you're looking for speed: look elsewhere. There's nothing to optimize here.