Perl isn't slow (compared to say, C) because it's interpreted. It isn't interpreted in the way we normally think about interpreted. Perl code gets compiled before it can be run - Perl just doesn't have a separate compiling phase. But the speed gain from caching the compilation is small. Perl is slow because it's so flexible. It allows for things like:

    push @array => splice @list, $foo, $bar, @new;
    $str .= "whatever";
[download]

And throw in memory management, dynamic scoping, AUTOLOADING, evalling and lots of other things that make it fun to program in Perl, and you will have a significant speed penalty to pay. Compiling will not solve that - you still will need to do the same steps Perl is already doing (and it's doing them in C code).

If for whatever reason you rather ship a binary instead of Perl code, you could always write a small C program, embed perl in the program, and pass your Perl program as a C string to the embedded perl interpreter. You might want to do some mungling of the code to defend against a strings attack.

Of course, the real defence against "source code" stealing is by using proper contracts. I used the work for a company that sold software, often for prices over $1,000,000. We threw in the source code (C) for free (many dozens of Mbs) for any customer requesting it. For some customers, being able to get the source code was a must - it needed to be auditted. We never run into any problems of code being "stolen". But we did get bugfixes this way.

Abigail