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-performanceHappy 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.