{$val} содержит меньше синтаксического мусора, чем <? echo $val; ?>, а уж тем более, чем у <? echo $this->val; ?>
Когда таких параметров становятся десятки, в одном случае мы видим аккуратный HTML с вставками, в другом — тонну закорючек :)
…
Мне, как бы, сейчас приходится и на Smarty шаблоны использовать, и на PHP, благо, фреймворку моему пофиг, какой вид юзать, использование унифицировано. Так вот, Smarty — на голову компактнее и нагляднее. И PHP используется только когда или уж совсем скорость критична, или когда логика очень сложная и 3/4 шаблона — из кода состоит :D
…
А так — надо будет сабж прикрутить, оценить. Синтаксис там чуть более громоздкий, чем у Smarty, но терпимый. М.б. некоторые компоненты с большим числом вложений, на него переведу, если эффективен окажется.
Обработкой данных должен заниматься контроллер. Но он не должен заниматься шаблонизацией.
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
>верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали)
В буфере обмена оказалась другая фраза, сорри :D Должно было быть «зрение станет ещё хуже».
>Просто не нужно придираться к каждому слову
Так не я придираться начал :) Просто на категоричное утверждение возразил своим контрпримером. А придирки потом уже ко мне пошли. К тому же, не по существу. Ибо я не утверждал, что ношение очков как-либо влияет на улучшение зрения. Положительно и отрицательно.
Кстати, думаю, что приписывание оппоненту того, чего он не говорил или опровержение такового — это много хуже любой критики :)
Красиво, всё равно не обработаешь ошибку: «Вы увидите, что PHP отобразил стандартное сообщение об ошибке, но к нему в конец было приписано " — output is handled!", т.е. наш обработчик сработал.»
Так что уж проще потенциально проблемный код eval'у скармливать. Хоть мусора на экране не будет.
>Ага, а если оперативки <=, чем гиг, то использовать Висту тоже как бы бессмысленно.
Ну, почему… Пасьянс можно пораскладывать, или даже Word открыть со среднего размера документом :) На неразжиревшей Висте с гига приложению метров 400 остаётся :)
Вот про современные игры на гиге можно забыть. Тот же Gears of War уходит в непрерывный своп.
>ReadyBoost это вещь, особенно когда процессор под завязку нагружен расчетами
Я ещё раз напомню про DMA. Пока контроллер винчестера сам распихивает данные, а процессор может заниматься расчётами, в случае USB данные с флешки будет тащить сам процессор :)
При случайном чтении порций данных в 512кБ практически все 2.5" HDD имеют трансфер около 20Мб/с :)
А при реальной работе и чтение с диска достаточно далеко от случайного, и размеры блоков обычно побольше. Операционные системы имеют упреждающее чтение уже лет 15 даже у Microsoft :)
Но и сам контроллер денег будет стоит :) В сумме рублей под 800 того гляди набежит. Медленной и недолговечной USB-флешки :)
Так что тогда уже купить за 1800р. флешку на 4Гб с IDE-интерфейсом и иметь скорость чтения под 30Мб/с, миллион циклов записи и подключение как обычного жёсткого диска :)
Да, вдогонку. Естественно, что при выкачивании wget'ом с лимитом скорости в 1кБ (качается 50 секунд) цифры не меняются. На то она и буферизация. А уж отключать её для теста — извините, у меня этот сервер сейчас по 1,3млн хитов в сутки отбивает :D
Но это мизер на общем фоне затрат на инициализацию PHP-процесса и внутренние процессы. Упомянутый скрипт работает в течении… (запускаю ab) 50мс.
Так что даже ob_start обрабатывается только в течении 1/50 всего времени. Даже десятком ob_start вызовов можно пренебречь на фоне пустого скрипта. Если же он у нас будет полноценный, с работой с БД, обработкой результатов и будет выполняться хотя бы 0,1 сек — то эта проблема вообще не встаёт.
{$val} содержит меньше синтаксического мусора, чем <? echo $val; ?>, а уж тем более, чем у <? echo $this->val; ?>
Когда таких параметров становятся десятки, в одном случае мы видим аккуратный HTML с вставками, в другом — тонну закорючек :)
…
Мне, как бы, сейчас приходится и на Smarty шаблоны использовать, и на PHP, благо, фреймворку моему пофиг, какой вид юзать, использование унифицировано. Так вот, Smarty — на голову компактнее и нагляднее. И PHP используется только когда или уж совсем скорость критична, или когда логика очень сложная и 3/4 шаблона — из кода состоит :D
…
А так — надо будет сабж прикрутить, оценить. Синтаксис там чуть более громоздкий, чем у Smarty, но терпимый. М.б. некоторые компоненты с большим числом вложений, на него переведу, если эффективен окажется.
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
Подтверждаю этот опыт личной практикой :)
Синтаксис избыточный. Там, где в Zend_View нужно писать:
<?php echo $this->escape($val['author']) ?>
в том же Smarty пишется:
{$author|escape}
Зависит от /proc/sys/vm/swappiness
Можно сделать так, чтобы своп юзался только когда памяти совсем нет. Можно — так, чтобы в своп сбрасывалось всё по каждому чиху :)
Вот я потому сейчас WikiTeX и использую как внешний модуль. Но достало из-за того, что в Wiki API часто меняется, постоянно переписывать :)
…
А так, скорее всего, воспользуюсь рецептом из habrahabr.ru/blogs/php/45292/#comment_1143720
В буфере обмена оказалась другая фраза, сорри :D Должно было быть «зрение станет ещё хуже».
>Просто не нужно придираться к каждому слову
Так не я придираться начал :) Просто на категоричное утверждение возразил своим контрпримером. А придирки потом уже ко мне пошли. К тому же, не по существу. Ибо я не утверждал, что ношение очков как-либо влияет на улучшение зрения. Положительно и отрицательно.
Кстати, думаю, что приписывание оппоненту того, чего он не говорил или опровержение такового — это много хуже любой критики :)
Каталог со шрифтами, вроде, корректный…
Прочитал, наконец.
Красиво, всё равно не обработаешь ошибку: «Вы увидите, что PHP отобразил стандартное сообщение об ошибке, но к нему в конец было приписано " — output is handled!", т.е. наш обработчик сработал.»
Так что уж проще потенциально проблемный код eval'у скармливать. Хоть мусора на экране не будет.
Ращницу между «станет хуже» и «не станет лучше» улавливаете?
Ну, почему… Пасьянс можно пораскладывать, или даже Word открыть со среднего размера документом :) На неразжиревшей Висте с гига приложению метров 400 остаётся :)
Вот про современные игры на гиге можно забыть. Тот же Gears of War уходит в непрерывный своп.
С двумя же гигами ситуация сразу исправляется :)
Естественно, нельзя. Но какое это отношение имеет обработке ошибок и к буферизации вывода сервером? Это совершенно разные буферизации :)
>ты видимо не читал: dklab.ru/chicken/nablas/45.html
Посмотрел. Зачем мне перехватывать фатальные ошибки? У меня в нормальном коде их просто не бывает :)
В общем, ограничений только меньше, чем без буферизации :D
Я ещё раз напомню про DMA. Пока контроллер винчестера сам распихивает данные, а процессор может заниматься расчётами, в случае USB данные с флешки будет тащить сам процессор :)
www.fcenter.ru/online.shtml?articles/hardware/hdd/24528#05
При случайном чтении порций данных в 512кБ практически все 2.5" HDD имеют трансфер около 20Мб/с :)
А при реальной работе и чтение с диска достаточно далеко от случайного, и размеры блоков обычно побольше. Операционные системы имеют упреждающее чтение уже лет 15 даже у Microsoft :)
Но и сам контроллер денег будет стоит :) В сумме рублей под 800 того гляди набежит. Медленной и недолговечной USB-флешки :)
Так что тогда уже купить за 1800р. флешку на 4Гб с IDE-интерфейсом и иметь скорость чтения под 30Мб/с, миллион циклов записи и подключение как обычного жёсткого диска :)
Хотел отпостить отдельным сообщением в свой блог, чтобы не связываться с подобной лексикой, но, видно, кармы у меня не хватает, поэтому тут опишу.
Мне так кажется, что ты немного не в теме. Потому что буферизация не «просирает» выигрышь, а, наоборот, позволяет его сохранить.
Итак, тест. 100 отдельных выводов строки по 100 байт (итого — 10кБ) через echo и один общий после стократного суммирования строки:
out_echo_multi: 0.000110864639282
out_echo_one: 0.00011420249939
Как видим, буферизация позволяет вывести разницу между одним выводом и многими за уровень погрешности.
А что на счёт чистого непарсеного HTML? В смысле ?>some some some<?
Получается так:
out_php: 0.000123977661133
>Очень повеселила проблема того же хабраюзера с медленной работы ob_start().
Тоже всё относительно. Да, скорость снижается в 9 раз:
out_ob_multi: 0.000921010971069
out_ob_one: 0.000912189483643
Но это мизер на общем фоне затрат на инициализацию PHP-процесса и внутренние процессы. Упомянутый скрипт работает в течении… (запускаю ab) 50мс.
Так что даже ob_start обрабатывается только в течении 1/50 всего времени. Даже десятком ob_start вызовов можно пренебречь на фоне пустого скрипта. Если же он у нас будет полноценный, с работой с БД, обработкой результатов и будет выполняться хотя бы 0,1 сек — то эта проблема вообще не встаёт.
…
Сорец скрипта лежит на balancer.ru/test-out.php.txt, результат работы — balancer.ru/test-out.php