The Perl interpreter first compiles your program to bytecode and then executes it. Assuming your subroutine is defined in the program (and does not do any run-time trickery), it will be compiled in the first step.
There are some ways to compile things at run time -- eval a string or require a module or a program, for example. I think the compilation->execution fact answers your question.
Incidentally, the compile() function in CGI.pm only applies to autoloaded methods (generated at run time if a non-existent method is called in a package that has been set up to handle that sort of thing). | [reply] |
Yes, the CGI.pm uses tricks to avoid code being compiled by the perl interpreter at script parse time because it is such a big hairy module. Other large modules use similar tricks or tricks with a similar effect. For example, the 'Tk' module.
There is an AutoLoader.pm (in the standard distro) to help you do this kind of thing too if you think it necessary (but be sure you Benchmark first..."premature optimisation is the root of all evil").
One cool thing related to this is what happens when you call a function in an object in perl (using the perl OO syntax).
If I try to call function (or method if you prefer) 'foo()' for an object $bar which is an instance of a 'package Bar;' then perl will look first for a Bar::foo function.
If it doesn't exist (and after chasing up the inheritance heirarchy if the object derives from another) perl will try calling a function called Bar::AUTOLOAD.
This allows you to put in a generic "function not implemented" handler.
For autoloading, you can then pull in the original function but I have also seen (not written :-) code which uses this to implement a bunch of similar functions.
Simply don't implement any of them, but provide an AUTOLOAD method which works out which function was wanted and does the right thing.
| [reply] |
Subroutines are compiled when the their source file is initially encountered. For the main source file and any modules that are called through "use", this means at startup. (On the other hand, "require and "new" are run time statements.)
Method calls have a little bit of additional overhead, because perl needs to search the @ISA chain and find the package of the ancestor class which contains the method. On the first call to a method, perl caches the package that contains the subroutine, speeding things up for subsequent calls.
The UNIVERSAL::can() method can perform this lookup, and I believe it performs the same caching as the inital method call. | [reply] |
You are correct. UNIVERSAL::can() does use the normal method caching mechanism (depth-first, leftwards). Run-time inheritance changes are reflected in it.
Source: Damian Conway
| [reply] |