<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Hello all, </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I just wrote a blog post that makes reference to a post that popped up at the SUPPORT list that I believe is timely to your discussion here. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>More on Drupal and Usability</DIV><DIV><A href="http://lizasabater.com/more_on_drupal_and_usability">http://lizasabater.com/more_on_drupal_and_usability</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Interesting enough, here's another post at the SUPPORT list that ends with words that echo the usability issues I feel are involved with the module bloat discussion : </DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Courier" size="3"><SPAN class="Apple-style-span" style="font-size: 13px;">BTW, it would be so easy to be able to move body and title (and</SPAN></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT class="Apple-style-span" face="Courier" size="3"><SPAN class="Apple-style-span" style="font-size: 13px;">taxonomy) in the CCK configuration screen (they have fixed weight)</SPAN></FONT></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://lists.drupal.org/pipermail/support/2007-November/006752.html">http://lists.drupal.org/pipermail/support/2007-November/006752.html</A></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>/ liza</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><DIV><DIV>On 22.Nov.2007, at 01:22 PM, Khalid Baheyeldin wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">On Nov 22, 2007 4:41 AM, J-P Stacey <<A href="mailto:jp.stacey@torchbox.com">jp.stacey@torchbox.com</A>> wrote:<BR><DIV class="gmail_quote"><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <DIV class="Ih2E3d">Greg Holsclaw wrote:<BR>> Drupal 6 will better optimize this issue by allowing module developers<BR>> to better include only the needed files through the menu system, thus<BR>> reducing overall memory usage without adding much overhead for opening <BR>> more files. I am sure chx would give a better summary.<BR><BR></DIV>I was just thinking, what might be nice, then, is for there to be some<BR>standard way of componentizing a module, and bringing in bits of it based on <BR>the URL. I take it from the mention of menu that that's what D6 does?<BR></BLOCKQUOTE><DIV><BR>Module splitting has happened as part of D6, mostly along the lines of admin<BR>stuff and regular stuff. However, it can be further tuned to be more granular, <BR>but it has to be on a module by module basis. No general rule can work for all<BR>possible permutations.<BR><BR></DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <BR>If you introduce a precompiler to minimize the file hits in such a system as<BR>Khalid mentions, would that nullify the effect you're after on the memory?<BR>Do precompilers typically work within the allocated memory of the apache <BR>processes and hence bloat them just the same?<BR></BLOCKQUOTE><DIV><BR>Effectively, if you have a shared memory based op-code cache (e.g. APC), then<BR>yes, the splitting becomes moot. Remember that not all people can have an <BR>op-code cache (e.g. shared hosts), so there is benefit to those from splitting<BR>the modules.<BR><BR>Op-code caches do save memory, since the code is loaded ONCE, parsed, <BR>tokenized and stored as tokens. So, the memory footprint becomes less per <BR>Apache process.<BR><BR></DIV><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><BR>Cheers,<BR>J-P<BR><FONT color="#888888">--<BR>J-P Stacey <BR>+44 (0)1608 811870<BR><A href="http://torchbox.com" target="_blank">http://torchbox.com</A><BR></FONT></BLOCKQUOTE></DIV><BR><BR clear="all"><BR>-- <BR>Khalid M. Baheyeldin<BR><A href="http://2bits.com">2bits.com</A><BR> <A href="http://2bits.com">http://2bits.com</A><BR>Drupal optimization, development, customization and consulting.</BLOCKQUOTE></DIV><BR></BODY></HTML>