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 <[email protected]> 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.
