Greetings and Salutations

[Michael G Schwern]

On Thu, Feb 21, 2002 at 02:55:37PM -0800, Andrew Whalley wrote:
> what are peoples experiences with the perl complier?   I've had a play
> round and not had any problems.  Are the issues with it mostly performance
> or C code it produces sometimes a bit buggy?

perlcc?  ACHTUNG!  DER IST EXPERIMENTALCODENBUNG EN HEREN!  It likes
to do things like eat up 40 megs of memory just to compile a 10 line
perl program.  It also likes to not run things in BEGIN blocks (so
BEGIN { print "foo" } will not quite work right).  It currently only
passes approximately 70% of the core perl test suite (ie. taking each
test script in turn, compiling it, and seeing if it still passes).

Bytecode compiling appears to actually make your program load slower.
This might just be an artifact of the implementation, nobody's looked
into it.

We almost gave up on perlcc entirely in 5.8.  It was completely broken
for a while, but a white knight came along and performed some meatball
surgery and got it working again.

Basically, the original author (Malcom Beattie) has a life now, and
the only other person who really understood it (Simon Cozens) has
Parrot to worry about.  There's no run-time benefit of converting your
Perl program to C (since the resulting C code just calls the same Perl
API functions that perl itself uses) and the optimizing translator
(B::CC) doesn't yet do much optimizing and its an extremely
non-trivial problem to optimize Perl code without breaking things.

So I don't see perlcc firming up ever.


However, all hope is not lost.  There are a handful of tools to go in
and manipulate the opcode tree directly.  B::Generate and optimizer.pm
being interesting because you can actually write your own optimizer
for your Perl code in Perl.


-- 

Michael G. Schwern   <schwern at pobox.com>    http://www.pobox.com/~schwern/
Perl Quality Assurance	    <perl-qa at perl.org>	       Kwalitee Is Job One
gumballs have no paste
Tim's balls are so damn pasty
bend over and squeal
	-- |siv|