Front page | perl.perl5.porters |
Postings from September 2009
Hi Raphaelm (Raphael Manfredi) wrote: > Quoting Steffen Mueller <nj88udd02@sneakemail.com> from ml.lang.perl.porters: > :I wonder whether such an API wouldn't slow down the malloc routine > :because it would have to check for user-supplied implementations. But > :then again, I'm not known to be particularly clueful in all things C. > > The impact would be completely negligible. The only thing that is required > is that a table of function pointers to malloc(), realloc() and free() be > maintained by Perl and each time you want to perform a memory operation, you > dereference the pointer from this table. > > Since these would be used fairly frequently, chances are the addresses there > would be in the CPU cacheline from one of the L1, L2 or even L3 caches. > > Compared to the work that a malloc() routine or a free() routine has to do > anyway, the extra dereference impact will not be noticeable. That may well be. > :Quoting perlvars.h: > :PERLVARI(Grevision, U8, PERL_REVISION) > :PERLVARI(Gversion, U8, PERL_VERSION) > :PERLVARI(Gsubversion, U8, PERL_SUBVERSION) > > So accessing the PL_revision variable from C would give me access to Grevision? That is my understanding: embed_vars.h has PL_revision and PL_Grevision both defined to the above Grevision. Cheers, Steffen Cheers, SteffenThread Previous | Thread Next