Использую движок интернет-магазина, код в процедурном стиле с ООП классами (функциями), шаблонизатор.

В результате запуска index.php

$files = get_included_files();
$filesize = 0;
$i=0;
foreach($files as $file) {
    echo "$file  - ".filesize($file)."<br/>";
    $filesize +=filesize($file);
    ++$i;
}
echo $filesize.' '.$i;  

- 50 подключаемых файлов (модули, функции, классы, константы, библиотеки)
- 530 536 байт

Нашел статью http://habrahabr.ru/post/112474/

Вы скорей всего упретесь в производительность в чем то другом. Я бы о количестве файлов беспокоился в последнюю очередь, при том в этом плане есть несколько выходов.
Если посмотреть на таких монстров как Zend Framework или Symfony, то ваш объем и количество подключаемых файлов очень малы, а движки на этих фреймворках так и вообще вашу ситуацию ставят в ничто!(Magento например)

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Поэтому приложения на фреймворках получаются как говорят, "тяжелые". На один require у меня показаны затраты 0.001 с. Проверку делал может не правильно, перед require зафиксировал время и в начале подключаемого файла. Т.е. например, если у меня один из фреймворков 31M, то все файлы загружены ессно не будут, но те классы которые наследуются выходит что загружаютс в оперативную память. Выход есть - добавить мощность оборудованию. Просто меня интересуют именно приложения для простого хостинга, но масштабируемое. Сколько должен быть размер всех файлов чтобы оптимально было для пусть 100-500 пользователей одновременно.

Я бы лучше посмотрел в трассировку Xdebug. А если и действительно 0.001(зависит во многом от загруженности системы), то 50 файлов это 0,05с, время соизмеримое с затратами на пару средних запросов.
Зависит все от хостинга. Они ведь тоже разные бывают. Есть за 6$ в год, а есть за 5$ в месяц.
Нужно идти, от того, что даст максимальный прирост производительности к минимальному. А не наоборот как делаете вы.
Пока вы ковыряете эти несчастные файлы, которые могут дать скажем 3-5% прироста производительности. Можно было бы соптимизировать запросы или создать кеш и выиграть 50%.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

В Xdebug тоже нужно будет проверить, но на более тонком уровне проверки. Вопрос в том, как определить эффективность php кода, если 531kb php кода генерирует 12kb html кода.

Так зависит и от того, что код выполняет. Насколько интенсивное использование БД и т.д.
Я могу написать код в пару килобайт, который положит БД на раз два. То есть объем не показатель. Показатель, насколько эффективно код выполняет свои обязанности, насколько интенсивно использует сторонние технологии и т.д.
Если абстрагироваться от всего этого, то пол мегабайта это немного. PHP не тот язык, который экономит память.(но не стоит только бросаться и раскидываться бездумно переменными!!!).
Все должно быть обоснованным, стремимся к легкой поддержке и расширяемости - значит больше файлов и кода. стремимся к скорости - пишем меньше кода, меньше файлов, но жертвуем расширяемостью.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Лучше посмотреть на работу движка ZendEngine2 чем на фреймворки и волноваться по файлам. на производительность больше влияет структура кода.
Сами файлы (байт коды) кэшируются, если часто используются. Интерпретаторы давно переросли себя в этом.

TigrOK
Во многом по теме согласен. 0,5Мб - это немного, тоже хорошо. Вопрос не простой, вообще насколько актуальна деятельность тестера php приложений на крутых it фирмах или "работает, ну и ладно". Фрилансеры, вероятно игнорируют эту тему. Неумелые изменения кода в готовых движках (допустим протестированных) может снизить производительность. Как же протестить т.с. в домашних условиях на большие нагрузки.

Guest
Если кешируются ещё где-то, тогда memory_get_usage() возвращала бы различные результаты, а так что при первом вызове, что при последующих, результат не меняется.

В одном своем проекте использовал механизм autoload и кучу мелких классов (~200Кб).
Рассчитывал, что чем меньше подключается классов - тем лучше.
В результате в момент работы, подгружалось ~20 классов.

Потом задумавшись также, на эту тему, решил склеить все 200 Кб классов в один большой файл. Скорость подключения этого файла увеличилась в разы!! Причем, я всегда примененяю кеш APC

Поэтому, на своей практике могу сказать, рассчитывать на autoload - большое зло. Лучше слить все классы в один файл и это будет самый производительный способ.

Но если ваших скриптов понаписано 10 Мб, то в этом случае лучше разбить их на группы классов, и их подключать по необходимости.