tomazos has asked for the wisdom of the Perl Monks concerning the following question:

I have inherited a proprietary testing system that uses 200 individual Perl scripts for each test case of an external device (over a serial connection).

Each script uses a custom "Test" module, calls a start routine, does the test in perl using subroutines from it, and then calls an end routine.

On top of that we have a master perl script which calls each perl script (by running it with the system command) in turn.

We are having performance problems. I suspect because it is building a new perl interpreter and reloading the harnass module for each test case.

I want to convert the system over to using a single perl interpreter.

This would involve turning the perl scripts into modules I suspect, loading them somehow at runtime with the master script. (require, use, do, eval? )

Can anyone recommend a strategy as to making this change?


Replies are listed 'Best First'.
Re: Persistent Perl Interpreter
by phaylon (Curate) on Oct 06, 2005 at 15:32 UTC
    As a quick suggestion, how about PPerl?

    Ordinary morality is for ordinary people. -- Aleister Crowley

      Or maybe PersistentPerl, which will allow you to run many different scripts under the same interpreter using the -g (group) switch.

        Didn't knew that one, Thanks!

        Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Persistent Perl Interpreter
by mpeters (Chaplain) on Oct 06, 2005 at 15:42 UTC
    The above suggestions are good for getting a persistent perl interpreter, but if you wanted to just try and run them all under the same interpreter you could turn them into modules using Test::Class which your main harness script would use or require.

    -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier
Re: Persistent Perl Interpreter
by Roy Johnson (Monsignor) on Oct 06, 2005 at 15:39 UTC
    You might be able to change the system calls into dos. That would run them in the current environment. The only thing I think you might have to worry about is global variables persisting from one test to the next.

    Caution: Contents may have been coded under pressure.