(I've ignored the CCFLAGS output that is also produced.)
Just debug.
AIUI, the problem with defining PERL_NO_GET_CONTEXT in Inline::C scripts is that it causes breakage if any of the Inline::C functions call Perl API functions. But none of the functions in your script call Perl API functions, so it's ok to define PERL_NO_GET_CONTEXT.
Indeed. T'is unfortunate that almost every function that does anything useful needs to call at least one perl API.
It is the case that many, if not all-but-one, of the Perl_get_context() calls get optimised away, but getting your hands on the post-optimised assembly is only possible by using a debugger, and it means relating any bug back to the pre-optimised C is a nightmare.
Could it be that the hint that vr is looking for is simply to "define PERL_NO_GET_CONTEXT" ?
Possibly; but getting his hands on the assembler output would be the surest way of finding out. That has to be possible with gcc/mingw right?
I still think that the chances are that gcc is optimising his c-stub and perl callable wrapper away completely.
In reply to Re^7: Inline::C on Windows: how to improve performance of compiled code?
by BrowserUk
in thread Inline::C on Windows: how to improve performance of compiled code?
by vr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |