[development] Conditionally include include files

[Larry Garfield]

I will be writing up the appropriate handbook page later tonight when I get home, and will follow-up in this thread with a link when it exists.  The outstanding optimization questions that I don't have a firm answer for yet are:

1) Are there any very-common page handlers that should be left in the main module file to avoid the extra disk hit (eg, node_page)?  We'll need to test and see what the extra disk hit cost is.

2) As a general rule for simplicity I am going to suggest in the docs modulename.pages.inc and modulename.admin.inc for user-side and admin-side pages respectively.  However, do we want to break it down even further?  How much breakdown is appropriate, though?  One file per handler would have the least extra code parsing overhead, but the most maintenance overhead for the developer.  I'm not sure what the right trade-off point is there.  It may also be different for core vs. contrib modules.

In addition to claiming modules to work on, if there are any pending patches that make substantial changes to a core module that need to go in before code freeze let us know about those, too, so we can not touch that module yet.  This performance refactoring can stretch post-1 June I believe since there's no API changes (Dries, correct me if that's an incorrect statement), and I'd rather not block someone else's patch that's almost-there. :-)

--Larry Garfield

On Tue, 22 May 2007 08:01:58 +0200, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> Hello world,
> 
> I just committed patch http://drupal.org/node/140218, which enables
> us to split module files into multiple (include) files.  With this
> patch, it is the router's (menu system) responsibility to load the
> correct include file -- i.e. the include file that has the active
> callback's code.  In other words, depending on the active callback,
> Drupal can conditionally load include files rather than having to
> load the entire world.
> 
> This is an important patch as it enables us to load less code --
> hence, it can offer an important performance boost.  Kudos to all the
> people who helped make this possible.  :-)
> 
> The patch that has been committed implements the system to accomplish
> that, but doesn't actually split modules.  There is only one new .inc
> file that has been committed with this patch that acts as an example.
> 
> Now this patch landed, the natural next step would be to fire up your
> profilers, and to split a couple more big modules in Drupal core --
> and to report back the performance improvements that you observe with
> that.
> 
> --
> Dries Buytaert  ::  http://www.buytaert.net/