Can I tell Perl that some data are immutable to speed things up?

Answer 1

You can set the SvREADONLY flag on a variable with Readonly::XS, but that does not improve the efficiency. Efficiency comes from choosing the right algorithm, not through compiler hints. If you want your code to be faster/use less memory then profile it (see Devel::NYTProf). When you find a bottleneck either use a different algorithm there or switch to use XS.

Also, if you are going to try to optimize something, make sure the result really is faster, here is substr vs unpack:

            Rate unpack substr
unpack 2055647/s     --   -74%
substr 7989875/s   289%     --

Here is the benchmark code.

#!/usr/bin/perl

use strict;
use warnings;

use Benchmark;

my %subs = (
    unpack => sub { return unpack "a3", "foobarbaz" },
    substr => sub { return substr "foobarbaz", 0, 3 }
);

for my $sub (keys %subs) {
    print "$sub => ", $subs{$sub}(), "\n";
}

Benchmark::cmpthese -1, \%subs;

Answer 2

I remember reading in some article (please comment if you can place it) that you can hint perl that you will not modify some variable and thus it removes the extra baggage that is otherwise required if you were to modify it etc?

Would I be right in assuming you are talking about 'use constant...' ?

Answer 3

I'm with Chas, benchmark and profile your code first. I really doubt string copying is your bottleneck and you'll waste an awful lot of time for little gain. Even if string copying does appear to be the bottleneck, look for a flawed algorithm in your code first. One of the great potential performance boosts of Perl over C and Java is because it's so fast to write code it leaves you with plenty of extra time to profile and optimize and improve the algorithm.

If string copying really is your bottleneck, consider simply passing around large strings as references. The moral equivalent of a string pointer in C. This will prevent copying. Remember to dereference them before you use them.

sub foo {
    my $ref = shift;

    print $$ref;
}

$string = "Some string";
foo(\$string);

Answer 4

in general:

Use good algorithms and don't optimize unless it is necessary. If it is, profile your code and benchmark your changes. This is a good time to consider XS or Inline::C as needed.

a (const *) char equvialent:

use constant Foo => 'bar'; creates a minimal subroutine that can be inlined by the perl compiler. You can also create your own inlineable constant functions

avoid extra copying:

The typical perl idiom does some "extra" copying:

sub foo {
    my $bar = shift;

    ..do stuff with $bar...
}

Many people do not realize that Perl passes arguments to subroutines by reference. @_ contains aliases to the arguments of a subroutine.

So you can avoid copying your arguments by working with @_ directly:

foo( $big_scalar );

sub foo {
    ..do stuff with $_[0]...
    .. sneakily risk modifying $big_scalar ..
}

Of course, this is risky, since if you modify the value, you will modify the calling value. Use this only when you need to save a BIG file copy. (Or you explicitly want to modify a calling argument.)

If I need to move a big, chunk of data around, but am not going to modify it, I usually pass it by reference explicitly, rather than messing around with @_;

foo( \$big_scalar );
sub foo {
    my $bar = shift;
    ... do stuff with $$bar ...
    ... can modify $big_scalar, but the pass by ref is explicit ...
}

[P]remature optimization is the root of all evil

At least that's what Donald Knuth rather famously said. There is a lot of wisdom in this statement.

Incorrect optimization (code that purports to be an optimization, but isn't) is pretty bad, too.

Code for clarity first. Be sure to profile your code to find bottlenecks. Be sure to benchmark your optimizations, to make sure they work. Document your optimized code, keep some benchmark code handy -- tomorrow's compiler may not respond the same way as today's.