[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