[development] The Drupal Diet - Making bootstrap faster

[Larry Garfield]

On Thu, 10 May 2007 06:43:21 -0700, David Metzler <metzlerd at metzlerd.com> wrote:
> For some reason I was lying awake at night thinking about drupal boot
> strapping (dear lord help me).

I can recommend my therapist.  He's used to that by now. :-)

> And it occured to me that although
> the frequency of use is certainly the right measure to decide what to
> load, that it probably isn't by technology, so I came up with a
> couple of different ways to think about this.

I'm not sure what you mean by technology?

> BY MENU PATH
> 1) System stuff - api's etc that need loading all the time.
> 2) node viewing pages (node* paths/routes) (not so sure this would work)
> 3) User settings (not sure about this one, but maybe anything with a
> user* menu path
> 4) admin pages (basically everything with an admin/blah route path
>
> You could even consider doing the admin pages based on a permisssions
> test (access admin pages).   The module_name.module files would
> always load, but maybe there would be room for a
> modulename.admin.module or a modulename.user.module  file that would
> be conditionally loaded based on either path or user permissions or
> some other criteria.
>
> BY NAMESPACE
> Or alternatively a namespace based approach where when a module is
> going to make a call that relies on another module it basically does
> an "import" of  namespace (the way its done in java)  This would make
> a bootstrap call that would load the modules that claim that
> namespace. (etiher in .info files or in a hook).

By permission is interesting.  Tweaking menu_execute_active_handler() to do the permission check first before the include should be trivial, and be a small performance boost on 403 pages.

That said, right now the patch is breaking down code by module and by function.  The "by function" part is up to each module author to decide.  That's better than forcing an "admin pages", "other pages", "node pages", etc. split because we'll only ever call one page callback per page load.  Why load all 70 admin page callbacks when we're only using one of them?  The extreme case is one page callback per file, but I don't think that's a wise way to go in most cases.  Different modules, though, will "fit" with different breakdowns.  That should be flexibility left to the module author.

The namespace approach is what chx suggested with magic function loading.  I experimented with it, but eventually decided it was too opaque to deal with at this stage.  I want to stick to page callbacks for right now, as those are the biggest dead weight on most page calls.

More info in the issue queue: http://drupal.org/node/140218 .  Reviews welcome. :-)  The sooner we can get this in, the sooner we can start optimizing core.

--Larry Garfield