did it make any difference if you rewrote test2() to use the perl abstraction layer ?

I didn't try...nor will I. I will never opt for adding a layer, when I can achieve my aim by removing one. (Or 3 or 4 :)

I'm afraid this is a prime example of why I avoid doing anything serious with the P5 sources, and a prime example of what is wrong with source-level macros (and backward compatibility) in general.

As each new generation of maintainers works on a system, they add new layers of macro wrappers to incorporate their latest thinking, whilst maintaining BC code. The problem is that as each new layer gets added, about 50% of it is added not for architectural or system design reasons, but 'just in case'.

With each layer added, the programmers involved are further and further removed from understanding the implications of their additions and further and further away from understanding the final expansions. The result is that you end up with systems that require undocumented and undocumentable understanding of what you can and cannot do; what you must and must not do; in order for things to work.

Anytime new functionality is required, the only option is to start with a similar, existing piece of functionality that is known to work and make incremental changes to move it toward the desired functionality. It becomes almost impossible to generate new code from scratch because the rules and requirements for combining the layers upon layers of macros are simply undocumentable. It's copy&paste programming at it's very worst.

The best P5 example I know of this is the whole OO/vtable architected memory management layer that is wrapped over the malloc/realloc/free et al. in the win32/*.(h|c) sources. There are so many definitions and redefinitions of malloc that indirect through runtime filled dispatch tables (probably a legacy of reusing preexisting C++ sources and converting them for compilation by C compilers), that it is impossible to consider trying to unwind and simplify them because the patch would be so pervasive to the source tree.

This is the same basic problem I have with OO methodology, particularly MI, the effects of which can be seen quite clearly in a lot of CPAN modules, including some in the core. As each new abstraction is developed, methods are added to interfaces, often for no better reason than 'for completeness'. The result is simple functionality; functionality that should be and essentially is simple and fast, ends up being complex and slow because it goes through so many layers to reach the underlying actual, functional code. And as the layers of Perl code are translated to C, each Perl layer goes through the same C-level layers of macro expansion, over and over.

To witness this for yourself, track a few Perl-level calls that should result in a single call to the OS,from your perl program into the kernel using a disassembling debugger and see the number of times Perl_get_context() is called. It's ludicrous to the point of being frightening.