http://www.perlmonks.org?node_id=1004088


in reply to Re: Use of Autoloader in Modern Times
in thread Use of Autoloader in Modern Times

Whether you do it at "startup" or "runtime" is irrelevant over the lifetime of the process.

... until you run a preforking server and want to take as much advantage of COW as you can.

  • Comment on Re^2: Use of Autoloader in Modern Times

Replies are listed 'Best First'.
Re^3: Use of Autoloader in Modern Times (depends)
by tye (Sage) on Nov 16, 2012 at 00:48 UTC

    Which is one of the reasons why "load dependency at compile-time" vs "load dependency at run-time" should be decided by the environment (when possible). Modules that define new syntax must be loaded at compile-time. A huge fraction of modules don't need to be loaded at compile-time so it can be very handy to allow the invoker to pick which behavior.

    Almost all unit tests should delay loading modules since the process isn't going to live very long and isn't going to use the vast majority of functionality eventually reached by the dependency tree (so no reason to wait for all of the too-early initialization over and over). But you should have at least one unit test that specifies "load all dependencies at compile-time" so that you can very quickly tell if any dependencies are missing, even if you haven't figured out how to exercise every single one of them.

    Pre-forking servers should load dependencies at compile-time in the parent but at run-time in the children.

    Lots of command-line tools (especially in a corporate software development house) can benefit from loading dependencies at run-time, so that I can do something useful with the frobnitz repository management subsystem from my laptop without having to install all of the PDF, XML, e-mail, GD, and plotting modules despite parts of the frobnitz repository needing to know how to send e-mails with PDF and/or XML attachements, some of which contain bar charts as png files (while also not having to constantly groom the dependency tree to make selected dependencies optional or at run-time to get that benefit).

    - tye        

Re^3: Use of Autoloader in Modern Times
by jgamble (Pilgrim) on Nov 18, 2012 at 18:27 UTC

    ...until you run a preforking server and want to take as much advantage of COW as you can.

    Could you expand on that a bit? How does copy on write and preforking incline one to use autoloading?

    My own personal preference is to avoid it like a plaguish thing, but even my most massive module isn't on the same order as some CPAN monsters.

    (Update: fix the italics tags)

      If you have a preforking server and a modern operating system, you'll tend to save memory by loading everything before forking off children, because they'll share memory pages until something modifies them. That's the opposite of autoloading.