Re: 'constant' vs array (Ignore bad benchmarks: [mod://constant] arrays are (a little) faster!)

[BrowserUk]

A couple of people have benchmarked constant arrays in this thread, but they've both made the same mistake: not checking what their code is doing and thus drawing bad conclusions.

The problem is that this use constant ARRAY => qw(Title Section Subsection Class Category Degree Attempt CountOfCounts);; does not create an array.

It creates a subroutine which returns an array as a list; which accounts for the inefficiency.

On the other hand: This use constant ARRAY => [ qw(Title Section Subsection Class Category Degree Attempt CountOfCounts) ];; creates a subroutine that return a reference to the array, which you can then index efficiently (especially if you use enum for the indexes):

use constant ARRAY => [ qw(Title Section Subsection Class Category Deg
+ree Attempt CountOfCounts) ];;
use enum = qw(Title Section Subsection Class Category Degree Attempt C
+ountOfCounts);;
@array = qw(Title Section Subsection Class Category Degree Attempt Cou
+ntOfCounts);;

cmpthese -1, {
    var => q[ 
        for(1..1e6){ 
            my $l = $array[ $category ]; 
        } 
    ],
    const => q[ 
        for(1..1e6){ 
           my $l = ARRAY->[ $category ]; 
        } 
    ],
    constenum => q[ 
        for(1..1e6){ 
            my $l = ARRAY->[ Category ]; 
        } 
    ],
};;
            Rate       var     const constenum
var       4.57/s        --       -1%      -18%
const     4.64/s        1%        --      -17%
constenum 5.57/s       22%       20%        --

[choroba]

The problem is such a reference is constant, but its members are not:

ARRAY->[0] = 'not so constant';
print ARRAY->[0];

[BrowserUk]

but its members are not:

I guess if you think you might 'accidentally' modify something you've defined as a constant that might be a problem.

But the primary uses of constant are:

1. Giving literals meaningful (symbolic) names.
2. Making it obvious to yourself and other programmers that this thing is a program defined literal by the use of a CLEARLY_DIFFERENT_SYNTAX.

   Even $UPPER_CASE doesn't achieve that (as well).

   Using variable name syntax for things that are not variable makes no sense.

3. Availing yourself of the optimisations that come from informing the compiler that this entity is not going to change.

   The oxymoronic read-only variables can not do this.