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

Re: Inefficient stat-ing of files?

Thread Previous | Thread Next
From:
bulk88
Date:
June 30, 2016 16:03
Subject:
Re: Inefficient stat-ing of files?
Message ID:
20160630160251.18127.qmail@lists-nntp.develooper.com
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 
http://search.cpan.org/dist/Acme-Win32-PEPM/ , 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About