On 8/30/07, Earl Miles <merlin@logrus.com> wrote:
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).
Loading less code is always a good thing, but on a good dedicated server with op-code caches, it is a diminishing returns situation, and the database becomes the bottleneck rather than code. Here are examples from a typical page load, for an authenticated user (hence no caching). The queries come from MySQL's query cache, and hence the short time. But, the entire page including the blocks, ...etc. takes ~60ms. Executed *121* queries in *22.04* milliseconds. Page execution time was * 82.45* ms. Executed *120* queries in *26.54* milliseconds. Page execution time was * 85.98* ms. I am not invalidating your point: shared hosts need the code optimization. Not only for speed, but memory footprint per process. But for dedicated? Far less so. Back to memory: can people try to replicate these results on both bloated sites and simpler ones? Also, how do we make memory measurement patchless (part in core, need Dries' blessing on this, and part in Devel). -- 2bits.com http://2bits.com Drupal development, customization and consulting.