view release on metacpan or  search on metacpan

perloptree.pod  view on Meta::CPAN

is done in most B modules. Best see L<B::Utils>.

You may also create custom ops at runtime (well, strictly speaking at
compile-time) via L<B::Generate>.

=head2 Modules

The most important op tree module is L<B::Concise> by Stephen McCamant.

L<B::Utils> provides abstract-enough op tree grep's and walkers with
callbacks from the perl level.

L<Devel::Hook> allows adding perl hooks into the BEGIN, CHECK,
UNITCHECK, INIT blocks.

L<Devel::TypeCheck> tries to verify possible static typing for
expressions and variables, a pretty hard problem for compilers,
esp. with such dynamic and untyped variables as Perl 5.

Reini Urban maintains the interactive op tree debugger L<B::Debugger>, 
the Compiler suite (B::C, B::CC, B::Bytecode), L<B::Generate> and 

ramblings/blogs-optimizing-2.md  view on Meta::CPAN

Specifying types via perl attributes, like `my $i :int;` would be nice also, but is technically impossible, since there is no compile-time method for attributes to be checked; only at run-time.

`B::CC` keeps a list of good ops (pp\_ functions), where the type or at least the number of arguments or return types is known at compile time. The same information is also available in the [Opcodes](http://search.cpan.org/dist/Opcodes/) module on CP...
Defined are op lists like, no\_stack, skip\_stack,  skip\_lexicals, skip\_invalidate, need\_curcop and for various other predefined op types needed for other optimizers or the Jit module. Does it branch, i.e. will it always return op->next or not?
Does it need to call PERL\_ASYNC\_CHECK?

On all unknown ops or ops which need to access lexicals, the current internal B::Stackobj::Padsv lexical stack values need to refreshed, written back from the internal compiler stack to the actual values on the heap, which is `PL_curpad[ix].` (sub wr...

So there is a lot of theoretical copying - "stack smashing" - going on.
But B::CC is cleverly keeping track of the stack areas which need to be written back, so in practice only the really needed values are handled.
In practice only numeric and boolean optimizations operate on private c variables on the C stack, rather than on referenced heap values, either on the perl stack or in the curpad. Simple sort callbacks also.
So only on unboxed numbers we need to copy the values back and force, before and after, as B::CC inlines most of these ops.

2. Benchmarks
-------------

I'll take a benchmark in which Perl is very slow compared to other scripting
languages, and which does a lot of arithmetic. Because I expect the
B::CC type optimizer to kick in, unboxing all the numbers, and inling
most of the arithmetic.