[development] Conditionally include include files

Larry Garfield larry at garfieldtech.com
Wed May 23 04:00:33 UTC 2007


Documentation here: http://drupal.org/node/146172

Wiki page to coordinate the refactoring effort here: 
http://groups.drupal.org/node/4179

Feedback on both welcome.

Note: If you are working on a page that has a heavy affect on a given module, 
please add it to the "Blocked on" list!  I'd rather we wait a week or three 
before splitting a module up than have a patch collision with something 
you're doing, thus wasting both your time and ours. :-)  

I've assigned myself aggregator to start since I don't think anything 
particularly interesting is happening with it, so it's reasonably 
collision-safe.

On Tuesday 22 May 2007, Larry Garfield wrote:
> 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/


-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson


More information about the development mailing list