[development] Drupal memory consumption (was: coding standard question)

Earl Miles merlin at logrus.com
Thu Aug 30 04:45:18 UTC 2007


Jeff Eaton wrote:
> My reading of the document is, "The basic bootstrap is a bit bulkier, 
> but modules are lighter." For pure core it's a bit of a wash, but I'm 
> betting that as more modules take advantage of the ability to split code 
> between different .inc files (admin.inc, etc), we'll see contrib getting 
> lighter, too.

There are quite a few steps in core we can take to reduce how much 
memory we use on bootstrap, at least from code. I'm a bit surprised that 
bootstrap has worsened, but I think the small size of the site is 
confusing things.

One of the places that Drupal really sucks memory is in that big honkin' 
menu cache. And that cache is gone. That's part of bootstrap.

In Khalid's report, the total bootstrap memory for the bloated site was 
10,975,408 bytes vs 5,319,968 bytes for the D6.x bootstrap. I suspect we 
  won't see that number go up nearly as much. With luck, contrib will be 
lighter.

Also, the splitting hasn't been completed, nor is it as completely 
efficient as it could be. In fact, due to the perceived difficulty of 
some of my initial proposals, we we ended up with is a really watered 
down version. We still have lots of hooks that are always being loaded, 
and sometimes I think it's been difficult to tell what APIs are used and 
what could go into include files. I think further analysis could really 
move things out.

Also, there are parts of core that are always loaded that probably don't 
need to be. We have a lot of APIs that could be well-served by analysis 
and if we think some APIs are lesser used, we could require a 'wakeup' 
type function to run in order to initialize said API prior to use.

I'm a lot more interested in the time it takes to bootstrap Drupal than 
I really am in how much memory we use, though. Loading code is one of 
the biggest timesinks in Drupal right now, and I think in Drupal 7 we'll 
want to try to move even further into the realm of making code optional. 
There is no reason that very simple pages can't run in 30ms, except that 
we generally spend 70ms (even on fast machines) loading code (let alone 
actually generating a page).
   	  	  	  	  	  	


More information about the development mailing list