in reply to Re-using Perl script into compiled programs

On my system, running perl -le 'print "Hello, World\n"' takes approximately 3ms, whereas the C equivalent is 1-2ms. Do you really need that last bit of speed? If you're not using any bloated modules, startup time of the Perl interpreter itself can be quite fast. If it's compiling a small (say, <1000 line) program, even on a 386 or sun4 machine, it takes less than a second.

Assuming a lot about your usage, practical experience says that you can pretty much keep `action scripts' or `agents' for remote management functions in Perl. This is the case with Tivoli for instance, which installs Perl onto every endpoint so that action scripts written in Perl are guaranteed to work. In fact, the worst performing agents in Tivoli were written in C; I had to re-write one or two of them in Perl, where the C program's mode of operation was so brain-dead that the interpreted solution with a better algorithm used less than 10% of the cpu time of the original.

Another option that permits a production Perl codebase is to have a persistent Perl daemon, that is signalled of events to by an external script or program with a lower latency - either from a real UNIX signal, writing to a named pipe, or perhaps a C program that collects the information in a minimalistic fashion and hands it to the running Perl daemon to process (starting that daemon if necessary, of course).

When it comes to performance, algorithms are key. Saying `C' is categorically faster than `Perl' shows a basic ignorance of the complete picture. When it comes to maintainability, code simplicity is the key. Therefore, keeping your core program logic in Perl gives you ultimate maintainability, and the flexibility to move to high performance algorithms without hundreds of hours of C coding. Since Perl runs in so many places, you then don't have to worry about maintaining ports of your program into different languages. Remember, the bare minimum you need on the client system to run a standard Perl script that uses no modules at all is the perl binary.

Otherwise, you can try embedding the Perl interpreter in your program, building a shared libperl.so that you link with (of course those two options are almost the same), or even getting your program to dump core on itself, turning the resultant core file into an executable with `undump'. My understanding is that the Perl to C compiler is still very experimental.