Экранирование литеральных констант в PHP

Об этой подлянки со стороны двойных кавычек я не думал раньше и она малозначительная

Если magic_quotes_gpc включены, то без разницы, какие кавычки — такая CMS будет экранировать что одинарные, что двойные.

интерпритатор дольше думает пытаясь отыскать переменную

Это вряд ли.

Код

$c = «a={$a}, b={$b}\n»;

и

$c = 'a=' . $a . ', b=' . $b . «\n»;

генерирует абсолютно одинаковый p-код (5 инструкций).

Почему все? Я юзаю одинарные.

генерирует абсолютно одинаковый p-код (5 инструкций).

А время этих генераций одинаковое?

Нет. Потому что все что в двойных надо проверить на наличие переменных и необходимость выполнения подстановки, а то что в одинарных тулим как есть. Это то же что в Tcl «» и {}.

Плюсую, время действительно разное. Но лично я, когда приходится писать на php, все-равно юзаю двойные кавычки. Эта привычка у меня с Си/Си++.

Что Вы такое пишите, что это время генераций так критично? У меня на 10,000,000 итерациях разница составила менее 0.3 сек.

А с использованием APC это вообще неактуально.

А время этих генераций одинаковое?

мб при таких запросах не стоит использовать языки сценариев?

PS - это для файла, размером ~280 МБ, в котором идут последовательно 10,000,000 присваиваний не самых короткиз строк, НЕ для присваивания в цикле.

Вообще не критично. Ну представь, ты приходишь в магазин купить ну скажем сахар. Есть две разных упаковки - одна 1кг ровно по цене 35 руб. и 1кг+одна песчинка по цене 29руб. Какой ты купишь?

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

плюсую неадекватность двойных кавычек там где не нужна интерполяция. ну тут ситуация такая же как с тем полчему конкатенируют строки для еха:

echo «foo», «bar», «blah»; <-- так надо писать, ящитаю

но все пишут

echo «foo» . «bar» . «blah»;

и еще что-то кукарекают, мол ЕСЛИ Я ТАМ ПОТОМ ВМЕСТО ЕХА НАПИШУ ЧТО-ТО ДРУГОЕ КО_КО_КО, короче, так они тебе и тут скажут, мол вдруг я потом там интерполяцию захочу

Производитель в данном случае один и доверия не вызывает вообще никакого.

Лучше вообще на PHP не писать. Этим вы убиваете сразу стаю зайцев.

В моем случае еще и сам убиваюсь голодом.

Некорректная аналогия.

Правильнее будет сравнить килограмм влажного сахара за 30 вечнодеревянных и килограмм хорошего за 35.

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

Если же у Вас производительность упирается именно в кавычки, Вы выбрали не тот язык для решения задачи.

echo «foo», «bar», «blah»; <-- так надо писать, ящитаю

Тогда уж

echo 'foo', 'bar', 'blah';

:-)

так они тебе и тут скажут, мол вдруг я потом там интерполяцию захочу

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

нуда нуда

Хорошо, а чем страдает читаемость? Тем что в таких вот выражениях '<span style=«color:green»>YES</span>' перед внутренними кавычками не стоит \?

В таких вот выражениях как раз всё отлично. А если присваивать/выводить строки с большим количеством текста и переменных, то, например,

«Case #{$case_id}: failed to submit optin proof for {$msgid} ({$case_id}, {$email}, {$referer}, {$joined}, {$ip})\n»

на мой вкус выглядит лучше, чем

'Case #' . $case_id . ': failed to submit optin proof for ' . $msgid . ' (' . $case_id . ', ' . $email . ', ' . $referer . ', ' . $joined . ', ' . $ip . ")\n"

Хотя, как вариант,

sprintf(«Case #%d: failed to submit optin proof for %s (%d, %s, %s, %s, %s)\n», $case_id, $msgid, $case_id, $email, $referer, $joined, $ip)

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