но вовсе не факт, что print + free выполняется медленнее, чем echo

Ну почему же? Внутренняя реализация print вызывает внутреннюю реализацию echo. Уже только поэтому print не может быть быстрее. Ну и еще необходимость выполнения FREE.

без приведения листингов этих функций бессмысленно

Эм… Листинг обработчиков опкодов занимают порядка мегабайта. На мой взгляд, приводить их несколько нецелесообразно. Тем более, что в них интенсивно используются внутренние макросы Zend Engine, которые не всегда очевидны.

Можно предположить, что второй блок выполняется медленне, но утверждать этого нельзя

Если Вы познакомитесь с Zend Engine поближе, то можно

INIT_STRING выделяет один байт памяти и создаёт строковую переменную.
ADD_STRING вызывает функцию add_string_to_string().
ADD_VAR преобразует переменную в строку и вызывает ту же add_string_to_string().

CONCAT вызывает функцию concat_function(), которая по функциональности эквивалентна ADD_VAR (с той разницей, что concat_function() не производит действий, характерных для обработчика опкода).

Что concat_function(), что add_string_to_string() — это, по сути, erealloc() + memcpy().

В первом случае получаем два распределения памяти и копирования, во втором — три (это не считая выделения однобайтового буфера). Плюс во втором случае получаем два лишних опкода, которые, к тому же, занимают место в памяти (причём нельзя сказать, что очень мало).

Приведённая цитата на Си вообще непонятно, как относится к вопросу.

Видите? Если бы я приводил код всех обработчиков, было бы мало смысла Та цитата показывает, что обработчик PRINT создаёт целочисленную переменную (возвращаемое значение) и вызывает обработчик ECHO. Но с используемыми именами макросов это не очевидно

но я впервые слышу это утверждение, а никаких ссылок в вашем сообщении нет

Всё-таки Вы невнимательно читали:

После этого я собрал (с поддержкой оптимизатора) и поставил eAccelerator и повторил тесты. Тест №1 и тест №2 дали одинаковый результат. Что характерно, eAccelerator самостоятельно преобразовал print в echo. Лапочка. Для теста №3 результат остался неизменным: там, собственно, нечего оптимизировать. А результаты теста №4 впечатлили.

Ну и плюс листинги.

Приведённая цитата на Си вообще непонятно, как относится к вопросу.
Про оптимизаторов довод единственно-хороший, но я впервые слышу это утверждение, а никаких ссылок в вашем сообщении нет.

Во-первых, лишний опкод производительности не добавляет (из-за издержек на его анализ/выполнение).
Во-вторых, внутренняя реализация print вызывает echo, из-за чего print не может быть быстрее:

В-третьих, оптимизаторы неспроста PRINT/FREE преобразовывают в ECHO.

в остальных рассуждениях подобный косяк повторяется.

1. Я работаю над проектом в котором одна из задач — массовая рассылка писем подписчикам. Каждое письмо «персонализируется» и т.п., затем отсылается. Подписчиков много тысяч. Слабое место отнюдь не почтовик, а PHP. Он реально тормозит. Множество спичек в цикле, выполняющемся десятки тысяч раз — это очень ощутимо. Говорю потому, что снёс xCache и поставил eAccelerator и включил оптимизатор. Рейт отправки вырос на 30%.
2. На хорошо нагруженных сайты типа littlefox.ru работа оптимизатора очень заметна — по падению Load Average и сниженной нагрузки на процессор. Железо на сервере не самое мощное, но оптимизация реально творит чудеса (я говорю не только про спички — пришлось написать пару плагинов и даже расширений PHP, чтобы компенсировать тормоза WordPress).

Вообще мне на ум приходит сравнение программ, скомпилированных Turbo Pascal 7.0 и Borland C++ 3: в Turbo Pascal оптимизатор отсутствует в принципе, а в BC++ его можно включить. Разница ощутима.

Я натравил оптимизатор на устаревшую локальную копию своего блога (интерпретатор обломался где-то после загрузки плагинов) и сравнил размер выдачи VLD:

• Без оптимизатора: 184,128 строк
• С оптимизатором: 180,707 строк

Разница (для не полностью загруженного WP) составляет 3,421 опкод. Полагая, что опкод выполняется 0.5 микросекунды (думаю, что для дешевых VPS это где-то рядом), имеем разницу в 1.7 миллисекунды. На полностью загруженном WordPress разница будет видна сильнее. Использование оптимизатора — бесплатный способ снизить нагрузку на сервер.

Да и как это будет сказываться на “производительности” самого интерпретатора?

Положительно. Компиляция и оптимизация будут выполнены один раз, после чего результат будет закэширован в shared memory.