[development] reducing module size

[Carl Wiedemann]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110202/7301abc6/attachment-0001.html