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.