in reply to Re: Huge perl binary file
in thread Huge perl binary file

This is a nice explanation. The perl executable is really just a specific use case of what is documented in perlembed. In this case, Perl is embedded in perl. How it's linked is what is in question; static versus dynamic. If is not statically linked, it will be pulled in as soon as it's needed. If it's statically linked, it gets included at startup time.

I don't know enough about the internals to know the answer to the following question, but in practical terms I hardly see how it matters: The question: Which of the following commands from Perl's API results in a dynamically-linked being pulled in: PERL_SYS_INIT3(), perl_alloc(), perl_construct(), perl_parse(), or perl_run()?

The thing is, I doubt that it matters which one triggers the dynamic loading, because they're probably called in close succession within the perl executable. perlinterp discusses how perlmain.c is really just a concise, high level wrapper around the code that appears in perl.c, and that it looks a lot like the embedding example in perlembed. The little 16k wrapper doesn't maintain its slender memory footprint for very long. Certainly by the time Perl begins parsing code it has already found a need that requires pulling in is probably loaded (under a non-static link build) before you have time to sneeze, relegating the distinction between start-up time for static vs dynamic linking to the dustbin of micro-optimization.


Replies are listed 'Best First'.
Re^3: Huge perl binary file
by dave_the_m (Monsignor) on Jul 14, 2012 at 09:14 UTC
    I would expect to get linked in when the perl executable is first loaded, and before any functions are called: the loading isn't triggered by calling a particular function. Of course, this is OS specific.