Alexandr Во-первых, у
RomikChef одномерный массив, который (по этому источнику) выносить не надо. Да и вообще если уж это не присваивание переменной, а вывод echo/print, то лучше использовать запятые, а не точки (там таких тестов не проводили, но полагаю, что по сравнению с точками ускорение будет намного ощутимее, чем у точек по сравнению с внутристрочным написанием).
Во-вторый, уже у меня не совсем многомерный массив (который "надо выносить"), а 2 одномерных массива (элемент одного - это индекс другого). Именно такого эксперимента там не рассмотрено, поэтому в этом случае однозначно говорить, что так хуже мы не можем, пока не подтвердим экспериментом (а я эксперимент ставить не буду, ибо меня этот вопрос вообще мало чешет).
В-третьих, я данные той статьи не проверял сам
, а потому степень моего доверия к тем данным <100%. Поскольку интуитивно + основываясь на моих знаниях и представлениях о компиляции/интерпретации мне кажется, что не дожно быть это медленнее (конечно, в исходники ПХП я не полезу - не такой это важный вопрос). А если даже в статье даные верны, то 20% - для меня вполне допустимо.
В четвертых, не ставился эксперимент, а потому неизвестно, что будет с соотношением времени при большом числе переменных в строке и, соответственно, с большим количеством конкантенаций (точек). Я лично думаю, что ситуация повернется с точностью до наоборот. Предпосылки такие:
- Точка - это одна операция конкантенации строк. Для каждой такой операции нужно выделить буфер под результат и скопировать в него по очереди 1-ю и 2-ю строку.
- У ПХП есть некий "компилятор", который переводит исходный код в нечто более удобное и быстрое. Точка - это конструкция языка, переменная вне кавычек - тоже, и вся операция конкантенации, вероятно, транслируется в более быстрый байт-код.
- Для сторок же в двойных кавычках, по идее, на этапе выполнения (а не компиляции) запускается некий парсер, находящий в ней спецсимволы и переменные, и если переменная найдена, ее надо разобрать. Это, вероятно, медленнее, чем синтаксический разбор при компиляции.
В этом я, собственно, как не уверен, как не уверен и в том, что строки на этапе компиляции совсем-совсем не обрабатываются, но просто это возможное объяснение замедлению.
- Когда переменных больше 1, то для _каждой_ точки должна выполниться описанная выше процедура. Парсер же строки должен запуститься всего 1 раз.
- При малом количестве переменных точка может быть быстрее за счет оптимизации кода при компиляции. При большом же количестве переменных я очень подозреваю, как написал выше, что ситуация может повернуться наоборот, потому против выделения буфера под строку 1 раз + парсинг строки будет стоять много операций по выделению буфера и переливанию результатов.
В общем, реально как работает я ПХП не знаю, и все эти выкладки основаны на моих представлениях о том "как должно быть" и некоторых знаниях из теории трансляции, поэтому могут быть ошибочными. Но я считаю их довольно верояными.
В-пятых (одних из самых важных), в целом эти эксперименты и полученные данные - немного спекулятивные. Поскольку в нормальной более менее приличной программе все эти "ускоряемые" операции представляют относительно небольшой процент кода, и занимают относительно небольшой процент ОБЩЕГО времени выполнения. В итоге если такими мучениями по "оптимизации" мы получим ускорение оптимизированного кода даже на 30-40%, то общее ускорение составит, дай-то бог, процентов 10. Мне кажется, что для таких программ адекватнее будет свои силы посвятить оптимизации алгоритмов. Если же (что обычно и бывает) в программе активно идет работа с БД, то там вообще основное время будет занимать именно выполнение запросов СУБД, и с ними вообще эроценты повышения производительности будут незаметны.
Что же касается обычных среднестатистических скриптов, или же таких, в которых 2 килобайта кода "посвящены" принтам и эхам, то в 99.99% случаев оптимальность и быстродействие - некритичные для них величины
.
И если взять это все на фоне:
В-шестых, читабельность, понятность, красота кода, удобство работы с ним и модификации лично для меня - весьма важный критерий, намного поважнее проблемы будет ли моя программа выполняться 0.5 секунды или 0.52 секунды.
Основываясь на написанном, плевал я на оптимизацию методом выноса переменных (любого вида) из кавычек, а также на разные прочие оптимизации из той серии. Я предпочитаю писать красивый и удобный код.
Хостеры же такие "перегрузки" с моей стороны, думаю, как-нибудь выдержат...
