reducing module size
I have a module whose functions are only used by logged-in users, it provides nothing to 'Anonymous' users except for a block. I'm considering loading most of the functions only when $user->uid > 0 probably in hook_init() My question is, which functions would have to be loaded in order for things not to break, apart from the block functions (and any that it uses)? Any insights would be most welcome before I try it out. -- ----------------- Bob Hutchinson Midwales dot com -----------------
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files. In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit. -- Hai-Nam Nguyen (aka jcisio) http://jcisio.com On Wed, Feb 2, 2011 at 1:46 PM, Bob Hutchinson <hutchlists@midwales.com> wrote:
I have a module whose functions are only used by logged-in users, it provides nothing to 'Anonymous' users except for a block. I'm considering loading most of the functions only when $user->uid > 0 probably in hook_init()
My question is, which functions would have to be loaded in order for things not to break, apart from the block functions (and any that it uses)?
Any insights would be most welcome before I try it out.
-- ----------------- Bob Hutchinson Midwales dot com -----------------
You can split the module into several modules (which will, of course, have to be enabled). In your example, the block code could be in a separate module (see http://drupal.org/project/weblinks). However, any opcode caching that you use is going to keep more execution-ready code in memory than you might think. My last customer used e-Accelerator with a 32 MB cache size and this was a tremendous boost to performance, but with smaller memory (VPS, shared) installations, may not be the best idea. @jcisio: To be more precise, the hooks must be in your .module namespace. I found this by accident when I started playing with sub-modules. For example, create a xyz.module, then create xyz_sub.module with xyz_block(); you will find that the blocks are available as though they were in xyz.module. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr. ________________________________ From: jcisio It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files. In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
Before you go out and rewrite all your code, consider what your goals are with this. The decision, ultimately, should be driven by data, rather than perception. Also consider: Do you have performance benchmarks? Are you running an op-code cache? Is simply buying more RAM for the server less expensive than your time spent reconfiguring these modules? How does front-end performance affect page load comparatively? Food for thought. Performance optimization can come in many different flavors -- sometimes the low-hanging fruit is a better approach than radically altering your development practices. Also peruse some of the posts at http://groups.drupal.org/high-performance Happy tuning :) On Wed, Feb 2, 2011 at 8:34 AM, nan wich <nan_wich@bellsouth.net> wrote:
You can split the module into several modules (which will, of course, have to be enabled). In your example, the block code could be in a separate module (see http://drupal.org/project/weblinks). However, any opcode caching that you use is going to keep more execution-ready code in memory than you might think. My last customer used e-Accelerator with a 32 MB cache size and this was a tremendous boost to performance, but with smaller memory (VPS, shared) installations, may not be the best idea.
@jcisio: To be more precise, the hooks must be in your .module *namespace*. I found this by accident when I started playing with sub-modules. For example, create a xyz.module, then create xyz_sub.module with xyz_block(); you will find that the blocks are available as though they were in xyz.module.
*Nancy*
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
------------------------------ *From:* jcisio
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files.
In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
greggles has pointed out to me that if you know what your target site is, and that site has a decent PHP cache, then any optimization about when to load code is wasted effort, because you should probably have all your code in memory all the time. -Randy On Wed, Feb 2, 2011 at 9:53 AM, Carl Wiedemann <carl.wiedemann@gmail.com>wrote:
Before you go out and rewrite all your code, consider what your goals are with this. The decision, ultimately, should be driven by data, rather than perception. Also consider: Do you have performance benchmarks? Are you running an op-code cache? Is simply buying more RAM for the server less expensive than your time spent reconfiguring these modules? How does front-end performance affect page load comparatively? Food for thought.
Performance optimization can come in many different flavors -- sometimes the low-hanging fruit is a better approach than radically altering your development practices.
Also peruse some of the posts at http://groups.drupal.org/high-performance
Happy tuning :)
On Wed, Feb 2, 2011 at 8:34 AM, nan wich <nan_wich@bellsouth.net> wrote:
You can split the module into several modules (which will, of course, have to be enabled). In your example, the block code could be in a separate module (see http://drupal.org/project/weblinks). However, any opcode caching that you use is going to keep more execution-ready code in memory than you might think. My last customer used e-Accelerator with a 32 MB cache size and this was a tremendous boost to performance, but with smaller memory (VPS, shared) installations, may not be the best idea.
@jcisio: To be more precise, the hooks must be in your .module *namespace *. I found this by accident when I started playing with sub-modules. For example, create a xyz.module, then create xyz_sub.module with xyz_block(); you will find that the blocks are available as though they were in xyz.module.
*Nancy*
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
------------------------------ *From:* jcisio
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files.
In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
-- Randy Fay Drupal Module and Site Development randy@randyfay.com +1 970.462.7450
Le mercredi 02 février 2011 à 10:00 -0700, Randy Fay a écrit :
greggles has pointed out to me that if you know what your target site is, and that site has a decent PHP cache, then any optimization about when to load code is wasted effort, because you should probably have all your code in memory all the time.
-Randy
I think Randy has the point here, never attempt to be smarter than the PHP interpreter or the OPCode cache. Using Drupal without without an OPCode cache is suicidal anyway. Pierre.
Hi, Ultimately I don't think that splitting out code is going to give you are huge benefit. However I find that splitting out the code multiple source files makes it a lot easier to maintain than 1 big file. easier to group functions. I never really like dealing with source files which are 1000-1500+ lines But ultimately a op code cache like e-Accelerator,APC or XCache will load and keep all these in memory anyway. Gordon. On 03/02/2011, at 3:53 AM, Carl Wiedemann wrote:
Before you go out and rewrite all your code, consider what your goals are with this. The decision, ultimately, should be driven by data, rather than perception. Also consider: Do you have performance benchmarks? Are you running an op-code cache? Is simply buying more RAM for the server less expensive than your time spent reconfiguring these modules? How does front-end performance affect page load comparatively? Food for thought.
Performance optimization can come in many different flavors -- sometimes the low-hanging fruit is a better approach than radically altering your development practices.
Also peruse some of the posts at http://groups.drupal.org/high-performance
Happy tuning :)
On Wed, Feb 2, 2011 at 8:34 AM, nan wich <nan_wich@bellsouth.net> wrote: You can split the module into several modules (which will, of course, have to be enabled). In your example, the block code could be in a separate module (see http://drupal.org/project/weblinks). However, any opcode caching that you use is going to keep more execution-ready code in memory than you might think. My last customer used e-Accelerator with a 32 MB cache size and this was a tremendous boost to performance, but with smaller memory (VPS, shared) installations, may not be the best idea.
@jcisio: To be more precise, the hooks must be in your .module namespace. I found this by accident when I started playing with sub-modules. For example, create a xyz.module, then create xyz_sub.module with xyz_block(); you will find that the blocks are available as though they were in xyz.module.
Nancy
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
From: jcisio
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files.
In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
It depends greatly on your server configuration. Splitting out page callback files in D6 was actually the biggest performance boost of that version, but made no difference either way on APC: http://www.garfieldtech.com/blog/benchmark-page-split --Larry Garfield On Wednesday, February 02, 2011 3:18:39 pm Gordon Heydon wrote:
Hi,
Ultimately I don't think that splitting out code is going to give you are huge benefit. However I find that splitting out the code multiple source files makes it a lot easier to maintain than 1 big file. easier to group functions.
I never really like dealing with source files which are 1000-1500+ lines
But ultimately a op code cache like e-Accelerator,APC or XCache will load and keep all these in memory anyway.
Gordon.
On 03/02/2011, at 3:53 AM, Carl Wiedemann wrote:
Before you go out and rewrite all your code, consider what your goals are with this. The decision, ultimately, should be driven by data, rather than perception. Also consider: Do you have performance benchmarks? Are you running an op-code cache? Is simply buying more RAM for the server less expensive than your time spent reconfiguring these modules? How does front-end performance affect page load comparatively? Food for thought.
Performance optimization can come in many different flavors -- sometimes the low-hanging fruit is a better approach than radically altering your development practices.
Also peruse some of the posts at http://groups.drupal.org/high-performance
Happy tuning :)
On Wed, Feb 2, 2011 at 8:34 AM, nan wich <nan_wich@bellsouth.net> wrote: You can split the module into several modules (which will, of course, have to be enabled). In your example, the block code could be in a separate module (see http://drupal.org/project/weblinks). However, any opcode caching that you use is going to keep more execution-ready code in memory than you might think. My last customer used e-Accelerator with a 32 MB cache size and this was a tremendous boost to performance, but with smaller memory (VPS, shared) installations, may not be the best idea.
@jcisio: To be more precise, the hooks must be in your .module namespace. I found this by accident when I started playing with sub-modules. For example, create a xyz.module, then create xyz_sub.module with xyz_block(); you will find that the blocks are available as though they were in xyz.module.
Nancy
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
From: jcisio
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files.
In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
Le mercredi 02 février 2011 à 13:54 +0100, jcisio a écrit :
It depends on which Drupal you are using, D6 or D7. Read the documentation about D7, where you can split your .module into multiple files.
In D6, in general, all hook implementations must be presented in your .module file. However, except your module is too big, this micro optimization has only negligeable profit.
-- Hai-Nam Nguyen (aka jcisio) http://jcisio.com
Module file split is almost the same in D6 and D7. The only real *big* thing added is the class automatic introspection in .info declared files that allows you to use the core autoloader. For the rest, you will stick to menu 'file' key usage. Please correct me if I'm wrong. Pierre.
Hi, to make a module load, the module can be an empty file but will not do much. For drupal 6.x you need to load in your hook functions into the .module file, but with things like hook_menu() you can specify which file to load when executing this menu item, which will allow you to move more out of the main module which is loaded everytime. With Drupal 7.x there you can move all your hooks out of the module file, since hooks can be registered and grouped they can be moved out into other files with the group, see http://api.drupal.org/api/drupal/modules--system--system.module/function/sys... which shows that some of the token hooks are registered and can be moved to a file modulename.token.inc Pity more hooks are not registered. There are also other things you can do like implement a hook implementation and then load an include file and execute the real function. Gordon. On 02/02/2011, at 11:46 PM, Bob Hutchinson wrote:
I have a module whose functions are only used by logged-in users, it provides nothing to 'Anonymous' users except for a block. I'm considering loading most of the functions only when $user->uid > 0 probably in hook_init()
My question is, which functions would have to be loaded in order for things not to break, apart from the block functions (and any that it uses)?
Any insights would be most welcome before I try it out.
-- ----------------- Bob Hutchinson Midwales dot com -----------------
In D6I tend to use the include mechanism provided in hook menu, but there is nothing wrong with including files as you need them... (e.g. At the beginning ofbthe hook block call. Loading them in init means they get loaded whether you use them or not. Sent from my iPad On Feb 2, 2011, at 4:46 AM, Bob Hutchinson <hutchlists@midwales.com> wrote:
I have a module whose functions are only used by logged-in users, it provides nothing to 'Anonymous' users except for a block. I'm considering loading most of the functions only when $user->uid > 0 probably in hook_init()
My question is, which functions would have to be loaded in order for things not to break, apart from the block functions (and any that it uses)?
Any insights would be most welcome before I try it out.
-- ----------------- Bob Hutchinson Midwales dot com -----------------
On Wednesday 02 February 2011, Bob Hutchinson wrote:
I have a module whose functions are only used by logged-in users, it provides nothing to 'Anonymous' users except for a block. I'm considering loading most of the functions only when $user->uid > 0 probably in hook_init()
My question is, which functions would have to be loaded in order for things not to break, apart from the block functions (and any that it uses)?
Any insights would be most welcome before I try it out.
Replying to my own mail here, I would like to thank all for the most interesting responses. I had already exploited the menu include method as far as I reasonably could, so I tried moving all the functions in the main module file (except for the hooks and their immediate dependencies) into a new file and loaded it in hook_init using module_load_include() so that they would only load when $user->uid > 0 This has worked just fine, both in D6 and D7 versions I also created a new install and enabled the module, works fine. (D7 only but I'm confident it will work in D6 too) Doing this has reduced the module's footprint by over 100k for anonymous user accesses, well worth while for a relatively minor file reorganisation. Randy Fay's point about PHP caching is interesting, for a HA site on it's own dedicated box loading all into memory is the way to go, but for your average Hosted site this would likely not be available so this method is useful. Thanks to all ;-) -- ----------------- Bob Hutchinson Midwales dot com -----------------
participants (9)
-
Bob Hutchinson -
Carl Wiedemann -
Dave Metzler -
Gordon Heydon -
jcisio -
Larry Garfield -
nan wich -
Pierre Rineau -
Randy Fay