Комментарии 29
wayly, я внимательно прочитал вашу статью, но честно говоря ничего не понял. Много текста, но о чем он — осталось загадкой. Текст может и полезен, но очень тяжело написан.
Зачем три версии одних и тех же скриншотов в разных местах? Досточно одной.
Более того, то о чем вы пишете — это экономия на спичках, и не стоит такоих сложных запутанных экспериметнтов. Но тем неменее.
Вывод :-) Тема не раскрыта, но за старания спасибо. Топику минус, в карму плюс. :-)
С наилучшими.
Зачем три версии одних и тех же скриншотов в разных местах? Досточно одной.
Более того, то о чем вы пишете — это экономия на спичках, и не стоит такоих сложных запутанных экспериметнтов. Но тем неменее.
Вывод :-) Тема не раскрыта, но за старания спасибо. Топику минус, в карму плюс. :-)
С наилучшими.
> Остается только добавить, что в программировании мелочей не бывает
Использование поговорки на умиляет голословности утверждения.
Бывает, бывает! Еще ох как бывает!
Использование поговорки на умиляет голословности утверждения.
Бывает, бывает! Еще ох как бывает!
Хех. Голословность? Цифры есть голословность? Вы меня удивили — честно.
Уверяю вас, я не собираюсь оставлять затеи с освещением возможной оптимизации кода на простейшем уровне. :)
Своей очереди ждут тесты схем обработки массивов, тесты производительности 2,3,4-мерных массивов, итераторов, столь популярных в последнее время геттеров/сеттеров (и прочих magic-вещей)…
Да и вопрос, имхо, стоит понимать несколько в другом свете: никто ведь не заставляет писать так, как я говорю: я всего-лишь привожу тесты разных подходов. Каждый вправе сказать «это мелочь» и не использовать — так ведь?
Только вот, в большинстве своем, наиболее шустрые и легкие техники являются стандартными, не допускающими либеральности. Это ли не есть чувство вкуса и красота кода? :)
Уверяю вас, я не собираюсь оставлять затеи с освещением возможной оптимизации кода на простейшем уровне. :)
Своей очереди ждут тесты схем обработки массивов, тесты производительности 2,3,4-мерных массивов, итераторов, столь популярных в последнее время геттеров/сеттеров (и прочих magic-вещей)…
Да и вопрос, имхо, стоит понимать несколько в другом свете: никто ведь не заставляет писать так, как я говорю: я всего-лишь привожу тесты разных подходов. Каждый вправе сказать «это мелочь» и не использовать — так ведь?
Только вот, в большинстве своем, наиболее шустрые и легкие техники являются стандартными, не допускающими либеральности. Это ли не есть чувство вкуса и красота кода? :)
Главное не забудьте потом вспомнить, что >80% времени, которое тратится обычным веб-скриптом, идёт на получение данных из БД. А писать на PHP скрипты-парсеры, работающие со строками не стоит, большую оптимизацию даст переход на другой язык.
Послушайте следующую мысль: она будет полезна.
1. Я не говорил ни о каком другом языке: в топике рассмотрен только PHP и только аспект «строка в PHP». Так что говорить о других языках — это как «Я тебе про Фому, ты мне про Ерему».
2. Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал. Лезьте в сошники и правьте — тогда поговорим. :)
Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Оптимизация ПО — процесс, затрагивающий каждый файл, каждую строку кода :)
1. Я не говорил ни о каком другом языке: в топике рассмотрен только PHP и только аспект «строка в PHP». Так что говорить о других языках — это как «Я тебе про Фому, ты мне про Ерему».
2. Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал. Лезьте в сошники и правьте — тогда поговорим. :)
Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Оптимизация ПО — процесс, затрагивающий каждый файл, каждую строку кода :)
Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал.
Грамотно спроектированная структура данных и нормальная работа с базой (например, не надо вызывать 'select * from table' в цикле) дадут куда большую оптимизацию, чем расстановка кавычек и разные способы конкатенации строк.
Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Бывает, когда за деревьями не видно леса и всесторонняя оптимизация становится латанием дыр треснувшего пополам корабля.
Грамотно спроектированная структура данных и нормальная работа с базой (например, не надо вызывать '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: три картинки, ибо хостеры изображений часто сносят оные по причине необращения. «На всякий случай».
Вся фишка в том, что работа со строками, изначально есть слабое место в 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: три картинки, ибо хостеры изображений часто сносят
Ну так вы напишите, что что это копии. Непонятно же… :)
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.
Да, игры с временем — весьма относительный (относительно наилучшего метода). Я знаю многих программистов, которые оперируют далеко не базовыми методами оптимизации. Тем не менее, перед релизом подобные вещи подвергаются рефакторингу :)
Не думаю, что они таким образом экономят время. Скорее, делают скрипты более стандартизированными, чтоли ;)
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 в том, что он похож на естественный язык и также естественно воспринимается. хотя, конечно, если Йода учитель ваш был…
вся прелесть 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 ')
тут тоже не надо ничего проверять, но все значения на своих местах.
тут тоже не надо ничего проверять, но все значения на своих местах.
Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее, но какой-нибудь тупейший запрос к бд или не поставленный/поставленный индекс, либо цикл в цикле сведет это все на нет.
И «генератор запросов» не просто так же используют от нечего делать…
А еще, как мне кажется, решающее значение имеет длинна строки.
И «генератор запросов» не просто так же используют от нечего делать…
А еще, как мне кажется, решающее значение имеет длинна строки.
Видимо, никто не читает полностью (не осилили? :)).
Я трижды сказал, что вопрос не только в быстродействии, но и восприятии кода
> Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее,
Видимо, вы плохо прочли статью либо не осилили ее. Вероятность того, что конкатенация будет быстрее возрастает только с увеличением строки, в которую необходимо подставить переменные. Это же очевидно по двум тестам.
Я трижды сказал, что вопрос не только в быстродействии, но и восприятии кода
> Ну знаете, можно долго кавычки заменять на одинарные, чтобы конкантенация была быстрее,
Видимо, вы плохо прочли статью либо не осилили ее. Вероятность того, что конкатенация будет быстрее возрастает только с увеличением строки, в которую необходимо подставить переменные. Это же очевидно по двум тестам.
мне вот так сложнее воспринимать:
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_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).
Внесите эту строку в нормальную IDE с подсветкой или на тот же dumpz — уверяю, будет выглядеть иначе, чем здесь (или на тот же dumpz).
А мне понравилась статья. Просто, но интересно.
В условиях работы с высоконагруженными серверами экономия на спичках при каждой итерации позволит сэкономить кубометры дров.
В условиях работы с высоконагруженными серверами экономия на спичках при каждой итерации позволит сэкономить кубометры дров.
Не хватает раздела «Итоги-Выводы» в конце статьи, с приведением таблицы результатов и т.п.
Наглядности тобишь конечной не хватает))
Наглядности тобишь конечной не хватает))
я думаю, что стоит ещё и heredoc протестировать.
Повидимому следующей статьей автора будет: «что выбрать для выводы echo или print».
Спасибо за старания, но это действительно оптимизация на спичках, хотя я и повторяюсь. Но как правило, я не видел еще ни одного сайта у которого были проблемы с быстродействим, и заменой print на echo, и вставку переменных в двойные кавычки на конкатенацию — эти проблемы решились бы. Как правило, есть гораздо более узкие места, в том числе как Вы и упомянули — архитектурные решения.
Спасибо за старания, но это действительно оптимизация на спичках, хотя я и повторяюсь. Но как правило, я не видел еще ни одного сайта у которого были проблемы с быстродействим, и заменой print на echo, и вставку переменных в двойные кавычки на конкатенацию — эти проблемы решились бы. Как правило, есть гораздо более узкие места, в том числе как Вы и упомянули — архитектурные решения.
те кому важна экономия на спичках не будут оптимизировать используя какие то одинарные кавычки для строк, а будут писать расширения на С для таких специализированых задач, тот же sql генератор например.
В чем автор прав — так это в том, что на Хабре наблюдается серьезный перекос в сторону фреймворков и вообще серьезного php-программирования. Это полезно и нужно, но немного обидно, что статей о технических деталях самого языка маловато.
А вот строки и их оптимизацию я бы вообще не рассматривал в контексте оптимизации кода и ускорения программы. Я бы скорее отнес это к стилям кодирования. Я думаю, что каждый из нас выбирает себе некоторый стиль работы со строками в зависимости от удобства написания программы и удобства чтения кода.
Мне например, удобнее использовать строки в одинарных кавычках с конкатенацией с переменными потому что: а.) сразу видны переменные в любом редакторе, б.) это пусть и совсем примитивное, «низкоуровневое», но все-таки разделение логики, которое дисциплинирует пишущего и упрощает понимание программы.
А вот строки и их оптимизацию я бы вообще не рассматривал в контексте оптимизации кода и ускорения программы. Я бы скорее отнес это к стилям кодирования. Я думаю, что каждый из нас выбирает себе некоторый стиль работы со строками в зависимости от удобства написания программы и удобства чтения кода.
Мне например, удобнее использовать строки в одинарных кавычках с конкатенацией с переменными потому что: а.) сразу видны переменные в любом редакторе, б.) это пусть и совсем примитивное, «низкоуровневое», но все-таки разделение логики, которое дисциплинирует пишущего и упрощает понимание программы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строки в PHP