In the latest measurements in my lab environment, the networked Win32 perl started up 6 times slower than a local copy of the same build (both ActiveState build 629). Sounds like a big problem, no? But even the network version was able to start up 1000 times in somewhere between 80 and 140 seconds, which means startup time on average was in the vicinity of a tenth of a second. Next, consider that this is a constant overhead which has little effect on the linear run time. In other words a script that actually does some work would show less difference, and the more work it does the smaller the difference.

Here are some results reported by other users of this configuration.

Next, consider some ClearCase-and-trigger-specific facts:

1. A trigger is always attached to a cleartool operation.
2. Triggers can only be attached to write operations. In fact the categories of opkinds have names like MODIFY_ELEM, MODIFY_TYPE, MODIFY_DATA, and MODIFY_MD.
3. As with any database transaction, write operations are much slower than reads.
4. Any trigger script that does something more than "exit 1" very likely invokes additional cleartool operations.

Thus any trigger script that falls into the "performance-sensitive" category likely involves at least two cleartool ops, with at least one being a slow write. In my lab environment I measured a typical read operation (ct ls foo) at 0.130 seconds and the common write ops checkin and checkout at ~1.3 seconds apiece. I didn't measure mkelem because I didn't feel like writing a script to create and remove 1000 elements but mkelem is certainly slower than ci/co. Some other write ops (mklabel?) are presumably faster.

My conclusions: while the startup time of a network perl is significantly more than a local copy, it's minor compared with the cost of even the one guaranteed ClearCase database write operation (~1/10th of a ci or co), and about the same as a read operation. Of course there are many many variables in play here and I'd be interested to see someone else's numbers. But based on all the data I derived, I believe a networked Perl is about 5-10% slower in trigger use while being immeasurably more robust and maintainable and thus wins hands down. IMHO.

As a corollary, the runtime cost of finding a Perl script, as opposed to the Perl interpreter itself, via the network vs a local copy is almost certainly negligible.

If anyone wants to derive similar numbers for their site, the script I used is below. BTW, my test environment is an old Sun Ultra10 440 workstation with 1GB RAM running Samba, plus an Athlon 1200 PC with 768MB RAM circa 2001. Presumably a more state-of-the-art setup would be faster overall though I have no idea how it would affect the ratios.

use Benchmark;
timethese (shift || 1000,
{
    ct_ls		=> sub { system 'cleartool ls -d foo >NUL' },
    'ct_co+ci'	=> sub { system 'cleartool co -nc foo >NUL';
				   system 'cleartool ci -nc -ide foo >NUL'
				},
    PerlLocal	=> sub { system 'C:/ASPerl/bin/perl -v >NUL' },
    PerlNet	=> sub { system '//fileserver/netperl/bin/perl -v >NUL' },
});

The Rules of Optimization

Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
- W.A. Wulf