sl@??? said:
> Actually I think that it still is interpreted. You just avoid the
> preliminary compilation of perl source to the intermediate structures
> that the perl run-time uses to actually run. I.e. as far as I know
> perl does not do native code generation.
Its good enough - basically it internally compiles to a set of calls to
perl library functions (waits for Malcolm Beattie to call foul). If
you have a system structured appropriately for perl where the seriously
expensive compilation stage is only executed once then perl is a real
win.
However wherever exim execs itself (to regain privileges) then the perl
stuff will need to recompile. You can structure the perl startup so
that compilation of all supporting perl libraries etc are done on exim
startup - see perl_startup config. Also by knocking down the security
settings - just running seteuid - then you make exim processes not need
to exec to regain privilege at the cost of less inherent security.
sl@??? said:
> And I do know that comparisions I have made between perl and c
> programs doing the same thing (after subtracting out the compilation
> phase or by running long enough that it is negligible) show that perl
> was orders of magnitude slower.
I am slightly stunned by this. In general I have found the difference
between doing serious work in perl and C to be within an order of
magnitude (assuming competent coding) and sometimes perl can be faster
because the people who wrote its library are very smart cookies.
Benchmarks can usually be made to prove whatever you wish, and perl is
certainly much faster to write a given function within unless you have
a very well provisioned C toolkit.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
