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 libperl.so 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 libperl.so 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 libperl.so. libperl.so 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.