|Problems? Is your data what you think it is?|
Several of the things I listed are not in your commandments. For example you say "don't tie", but you don't say "don't use variables supplied by other people, which may or may not be tied", such as %Config. You say "don't use lvalue subs", but you don't warn against "substr($x,1,2) = $y".
Maybe you want to actually look at the things I wrote and perhaps even download some RPerl code?
I had a quick look, but frankly my strength was sapped by your previous incomprehensible Part 8 post.
The thing I don't get (perhaps it's explained clearly somewhere, in which case I missed it), but what is the *point* of RPerl? Is it for making trivial blocks of perl code to run faster (but as soon as you want to do anything at all useful, you have to turn it off)?
It seems to be named in honour of RPython, but that has a very specific, limited use case, and this seems unrelated.
Also, I think the contribution of magic to making perl run slower is greatly overstated. The overhead that magic adds is a one-bit test with a conditional function call per variable access. There's still a big other bunch of overheads. For example polymorphic types. When you do something like
$a + $b
perl has to retrieve the the SVs from the current pad, check their 'get magic' flags and if set call mg_get() on them, then check whether overloading is enabled and if so call the overloaded add method, or failing that, try and convert
their values into integers or floats, possibly doing a string to integer conversion, or
Of all that, skipping the magic part is just skipping a 1-bit flag test - everything else still needs doing.
(In fact, the actual check in pp_add() or's the flags of the two SVs at the top of stack together, and calls a function if the combined bits indicate magic or a ref: the latter indicating possible overload).
In reply to Re^3: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments