develooper Front page | perl.perl5.porters | Postings from June 2016

Re: Inefficient stat-ing of files?

Thread Previous | Thread Next
June 30, 2016 16:03
Re: Inefficient stat-ing of files?
Message ID:
Craig A. Berry wrote:
> Somebody somewhere has probably used it as a generic
> override mechanism rather than for its intended purpose.
>> Having .pmc files that work could be a much greater optimization...
> My impression is that's just not gonna happen, but I'd be happy to be
> proven wrong.

AFAIK RPerl makes stub .pmc files that contain generated C++ code that 
is fed to Inline::* at runtime and then the XS shlibs area loaded into 
the process. If the XS shlib was already built and is loadable, by the 
nature of how Inline::* works, the existing shlib is loaded off disk and 
a recompile of C++ to a shlib doesn't happen.

B::Byteloader use .pmc for compiled modules and .plc for .pl analogs. 
ByteLoader's files are valid perl code, as the screenshot I include shows.

I also wrote this joke module , it produces .pm files 
that are also valid Win32 (XS) DLL files. If someone wanted it to be a 
serious module (or a serious packager), the PP+XS shlib file should be a 
.pmc on disk, not a .pm the way it is now. I also keep .pmc compile time 
disabled in my perls most of the time, so that was another selfish 
reason for PEPM to not use the .pmc extension.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About