Conditionally include include files
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/
I suppose it goes without saying that people interested in working on this seriously should coordinate and perhaps stake claims to modules so that efforts aren't duplicated. Robert Dries Buytaert 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/
Locale module is a very easy target there, since it already includes most of its code from locale.inc, and it has a custom menu callback which dates back to the time before this patch landed. It should be easy for someone to pick up and update to this new functionality! Gabor Robert Douglass wrote:
I suppose it goes without saying that people interested in working on this seriously should coordinate and perhaps stake claims to modules so that efforts aren't duplicated.
Robert
Dries Buytaert 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/
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@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/
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@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@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
participants (4)
-
Dries Buytaert -
Gabor Hojtsy -
Larry Garfield -
Robert Douglass