Le mercredi 02 février 2011 à 10:00 -0700, Randy Fay a écrit :
> greggles has pointed out to me that if you know what your target site
> is, and that site has a decent PHP cache, then any optimization about
> when to load code is wasted effort, because you should probably have
> all your code in me
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
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
On Wednesday 02 February 2011, Bob Hutchinson wrote:
> I have a module whose functions are only used by logged-in users, it
> provides nothing to 'Anonymous' users except for a block.
> I'm considering loading most of the functions only when $user->uid > 0
> probably in hook_init()
>
> My question
greggles has pointed out to me that if you know what your target site is,
and that site has a decent PHP cache, then any optimization about when to
load code is wasted effort, because you should probably have all your code
in memory all the time.
-Randy
On Wed, Feb 2, 2011 at 9:53 AM, Carl Wiedem
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
expensi
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
Le mercredi 02 février 2011 à 13:54 +0100, jcisio a écrit :
> 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. How
In D6I tend to use the include mechanism provided in hook menu, but there is
nothing wrong with including files as you need them... (e.g. At the beginning
ofbthe hook block call. Loading them in init means they get loaded whether you
use them or not.
Sent from my iPad
On Feb 2, 2011, at 4:46
Hi,
to make a module load, the module can be an empty file but will not do much.
For drupal 6.x you need to load in your hook functions into the .module file,
but with things like hook_menu() you can specify which file to load when
executing this menu item, which will allow you to move more out
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 ne
I have a module whose functions are only used by logged-in users, it provides
nothing to 'Anonymous' users except for a block.
I'm considering loading most of the functions only when $user->uid > 0
probably in hook_init()
My question is, which functions would have to be loaded in order for thing
12 matches
Mail list logo
