Как стать автором
Обновить

Комментарии 29

wayly, я внимательно прочитал вашу статью, но честно говоря ничего не понял. Много текста, но о чем он — осталось загадкой. Текст может и полезен, но очень тяжело написан.

Зачем три версии одних и тех же скриншотов в разных местах? Досточно одной.

Более того, то о чем вы пишете — это экономия на спичках, и не стоит такоих сложных запутанных экспериметнтов. Но тем неменее.

Вывод :-) Тема не раскрыта, но за старания спасибо. Топику минус, в карму плюс. :-)

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

Использование поговорки на умиляет голословности утверждения.
Бывает, бывает! Еще ох как бывает!
Хех. Голословность? Цифры есть голословность? Вы меня удивили — честно.

Уверяю вас, я не собираюсь оставлять затеи с освещением возможной оптимизации кода на простейшем уровне. :)

Своей очереди ждут тесты схем обработки массивов, тесты производительности 2,3,4-мерных массивов, итераторов, столь популярных в последнее время геттеров/сеттеров (и прочих magic-вещей)…

Да и вопрос, имхо, стоит понимать несколько в другом свете: никто ведь не заставляет писать так, как я говорю: я всего-лишь привожу тесты разных подходов. Каждый вправе сказать «это мелочь» и не использовать — так ведь?

Только вот, в большинстве своем, наиболее шустрые и легкие техники являются стандартными, не допускающими либеральности. Это ли не есть чувство вкуса и красота кода? :)
Главное не забудьте потом вспомнить, что >80% времени, которое тратится обычным веб-скриптом, идёт на получение данных из БД. А писать на PHP скрипты-парсеры, работающие со строками не стоит, большую оптимизацию даст переход на другой язык.
Послушайте следующую мысль: она будет полезна.
1. Я не говорил ни о каком другом языке: в топике рассмотрен только PHP и только аспект «строка в PHP». Так что говорить о других языках — это как «Я тебе про Фому, ты мне про Ерему».
2. Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал. Лезьте в сошники и правьте — тогда поговорим. :)

Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Оптимизация ПО — процесс, затрагивающий каждый файл, каждую строку кода :)
Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал.
Грамотно спроектированная структура данных и нормальная работа с базой (например, не надо вызывать 'select * from table' в цикле) дадут куда большую оптимизацию, чем расстановка кавычек и разные способы конкатенации строк.

Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Бывает, когда за деревьями не видно леса и всесторонняя оптимизация становится латанием дыр треснувшего пополам корабля.
НЛО прилетело и опубликовало эту надпись здесь
Ок. Отклонимся от статистики (таки математика элементарная — не всем ясна до конца).

Вся фишка в том, что работа со строками, изначально есть слабое место в PHP — так уж сложилось. В большинстве фреймворков используется генерация запросов к СУБД (в основном, конечно же, MySQL) средствами подстановки в строки значений.

Пример — $q = «SELECT „.$fields.“ FROM {$table} WHERE $conditions». Он является реальным, а не надуманным: использование трех методов генерации строки является, само по себе, противоречащим здравому смыслу.

Еще более веселым является использование генератора запросов а-ля
$result = DB:: query(«SELECT „.$fields.“ FROM %s WHERE $conditions», $table); Я, почему-то уверен, что 50% разработчиков приложений (и доработчиков, в том числе) встречались с такими конструкциями.

Поскольку, создание запросов, само по себе не является одиночной операцией (мне знакомы системы, которые создают по 50 запросов на вывод страницы) и не кешируется, в большинстве своем, то из спичек, собранных на таких мелочах можно построить нечто большее :)

Дело даже не в выигрыше во времени (он действительно будет плюшевым — 5 сотых секунды не играют роли при несущественных нагрузках), но больше в прививании подрастающему поколению «хорошего» стиля кодирования, подразумевающего некий стандарт, который, к тому же, является еще и более верным и логичным ;)

Offtop: три картинки, ибо хостеры изображений часто сносят оные по причине необращения. «На всякий случай».
> он действительно будет плюшевым — 5 сотых секунды не играют роли при несущественных нагрузках
5 сотых? 5 десятитысячных уж. И то в самом худшем случае.

>мне знакомы системы, которые создают по 50 запросов на вывод страницы
Вы познакомились с плохими системами. У вас время, которые выполняются 50 запрсов по сравнению с генерацией строк — это соотношение веса мухи и слона. Без малейшего преувеличения.

> $result = DB:: query(«SELECT „.$fields.“ FROM %s WHERE $conditions», $table);
Вот в этом как раз есть смысл. :-) Не так как в вашем примере, но использование такого вполне оправдано — и даже нужно. Как думайте, почему? :-)

> Offtop: три картинки, ибо хостеры изображений часто сносят
Ну так вы напишите, что что это копии. Непонятно же… :)

> Ну так вы напишите, что что это копии. Непонятно же… :)
1. Скриншоты профайлера (копии) располагаются…
2. Копии скриншота можно найти тут, тут и тут.

:)

По таблице видно, что 50 запросов — это тысячная секунды — тут я немного потерялся с нулями, аха — согласен.

На тему «Вот в этом как раз есть смысл. :-)», отвечу так: есть смысл в конструкциях типа
$query = sprintf(«SELECT %s FROM `%s` WHERE %s», '`name`,`surname`', DB_PREFIX.self::$db_table, «`id_user`=$id»);

В том же limb есть такое (первое, что встретилось)
$sql = «SELECT {$table}.* FROM {$table}, {$join_table}
WHERE {$table}.». $object->getPrimaryKeyName(). «={$join_table}.$foreign_field AND
{$join_table}.{$field}=». $this->owner->getId(). ' %where%';

Кто-нибудь может объяснить, на кой фиг смешивать 3 стиля подстановки значений в строку? Всему виной либерализм PHP.

Да, игры с временем — весьма относительный (относительно наилучшего метода). Я знаю многих программистов, которые оперируют далеко не базовыми методами оптимизации. Тем не менее, перед релизом подобные вещи подвергаются рефакторингу :)

Не думаю, что они таким образом экономят время. Скорее, делают скрипты более стандартизированными, чтоли ;)
в конструкциях вида «выбрать из где, имя-фамилия, таблица, 1234» смысла нет :-)
вся прелесть sql в том, что он похож на естественный язык и также естественно воспринимается. хотя, конечно, если Йода учитель ваш был…
$q = sprintf('SELECT %s FROM table WHERE id=%d', '`field`', $_GET['id']). $_GET['id'] можно и не проверять даже :)

$q= build_sql(' select field from table where id = ',$_GET['id'],' and 1 = 1 ')
тут тоже не надо ничего проверять, но все значения на своих местах.
А вот тут таки надо проверять. На SQL-инъекцию, хотябы ;)
не надо. упомянутая конструкция экивалентна:
$q= ' select field from table where id = '. mysql_real_escape_string( $_GET['id'] ). ' and 1 = 1 ';

функция экранирования, разумеется, выбирается в соответствии с подключённой субд…
Эм… данные автоматически эскейпятся? Ссылку на ман можно?
мана нет, но есть сорц: d-o-b.ru/?source:db.driver.sqlite

serialize — это и есть тот самый build_sql
Ааа, ну все понятно. Извиняюсь — «привидился» родной mysql_query
Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее, но какой-нибудь тупейший запрос к бд или не поставленный/поставленный индекс, либо цикл в цикле сведет это все на нет.
И «генератор запросов» не просто так же используют от нечего делать…
А еще, как мне кажется, решающее значение имеет длинна строки.
Видимо, никто не читает полностью (не осилили? :)).
Я трижды сказал, что вопрос не только в быстродействии, но и восприятии кода

> Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее,
Видимо, вы плохо прочли статью либо не осилили ее. Вероятность того, что конкатенация будет быстрее возрастает только с увеличением строки, в которую необходимо подставить переменные. Это же очевидно по двум тестам.
мне вот так сложнее воспринимать:
mysql_query('SELECT * FROM table WHERE id=\''.$_SESSION['id_user'].'\' ');
нежели так:
mysql_query(«SELECT * FROM table WHERE id='{$_SESSION['id_user']}' „);

а вам?
mysql_query('select * from table where id=«'. $_SESSION['id']. '»'); попробуйте — будет немного легче. Эскейпинг всега вредит восприятию.
mysql_query(«SELECT * FROM table WHERE id={$_SESSION['id_user']}»);
Внесите эту строку в нормальную IDE с подсветкой или на тот же dumpz — уверяю, будет выглядеть иначе, чем здесь (или на тот же dumpz).
А мне понравилась статья. Просто, но интересно.
В условиях работы с высоконагруженными серверами экономия на спичках при каждой итерации позволит сэкономить кубометры дров.
Не хватает раздела «Итоги-Выводы» в конце статьи, с приведением таблицы результатов и т.п.
Наглядности тобишь конечной не хватает))
я думаю, что стоит ещё и heredoc протестировать.
Повидимому следующей статьей автора будет: «что выбрать для выводы echo или print».

Спасибо за старания, но это действительно оптимизация на спичках, хотя я и повторяюсь. Но как правило, я не видел еще ни одного сайта у которого были проблемы с быстродействим, и заменой print на echo, и вставку переменных в двойные кавычки на конкатенацию — эти проблемы решились бы. Как правило, есть гораздо более узкие места, в том числе как Вы и упомянули — архитектурные решения.
те кому важна экономия на спичках не будут оптимизировать используя какие то одинарные кавычки для строк, а будут писать расширения на С для таких специализированых задач, тот же sql генератор например.
В чем автор прав — так это в том, что на Хабре наблюдается серьезный перекос в сторону фреймворков и вообще серьезного php-программирования. Это полезно и нужно, но немного обидно, что статей о технических деталях самого языка маловато.

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

Мне например, удобнее использовать строки в одинарных кавычках с конкатенацией с переменными потому что: а.) сразу видны переменные в любом редакторе, б.) это пусть и совсем примитивное, «низкоуровневое», но все-таки разделение логики, которое дисциплинирует пишущего и упрощает понимание программы.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.