I've added a memory usage check to the profiling output (requires that
PHP be compiled with --enable-memory-limit). It's pretty approximate and
probably wrong for whole functions (are local variables freed at the end
of the function?) but certainly is useful for the overall view and for
measuring chunks of code.
The last column of output is the sum of the increase in memory usage
over each invocation of that profiling point. (If it's all 0s, your PHP
is either older than 4.3.2 or compiled without --enable-memory limit.)
The default limit is a mere 8 megabytes, and this includes both data and
loaded & parsed code. On some hosts you're not allowed to increase the
limit, so we really want to be able to run within that; right now we
sometimes fail, for instance in rebuildMessages and Special:Allmessages.
The largest use of memory on common page views, though, is just _loading
the code_. Setup.php-includes section pulls in about four and a half
megabytes currently, way over half the default limit... trimming
unnecessary includes is a great way to save space and allow more
headroom for big operations. It also saves time; on a system without an
opcode cache, about half the runtime for a short page view time ends up
being in loading include files.
-- brion vibber (brion @
pobox.com)