Greg Holsclaw wrote:
> Drupal 6 will better optimize this issue by allowing module developers
> to better include only the needed files through the menu system, thus
> reducing overall memory usage without adding much overhead for opening
> more files. I am sure chx would give a better summary.

I was just thinking, what might be nice, then, is for there to be some
standard way of componentizing a module, and bringing in bits of it based on
the URL. I take it from the mention of menu that that's what D6 does?

Module splitting has happened as part of D6, mostly along the lines of admin
stuff and regular stuff. However, it can be further tuned to be more granular,
but it has to be on a module by module basis. No general rule can work for all
possible permutations.

If you introduce a precompiler to minimize the file hits in such a system as
Khalid mentions, would that nullify the effect you're after on the memory?
Do precompilers typically work within the allocated memory of the apache
processes and hence bloat them just the same?

Effectively, if you have a shared memory based op-code cache (e.g. APC), then
yes, the splitting becomes moot. Remember that not all people can have an
op-code cache (e.g. shared hosts), so there is benefit to those from splitting
the modules.

Op-code caches do save memory, since the code is loaded ONCE, parsed,
tokenized and stored as tokens. So, the memory footprint becomes less per
Apache process.

Cheers,
J-P
--
J-P Stacey
+44 (0)1608 811870
http://torchbox.com