[development] reducing module size

[Larry Garfield]

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