распространенные ошибки программирования на php

1. for($i=0; $i<count($ar); $i++) ...
   в этом случае функция count будет вызываться при каждом проходе цикла.
   Вообще по циклам можно дать следующие рекомендации:
   
   • sizeof() немного быстрее, чем count()
   • в циклах sizeof/count лучше заменять на переменную
   • for и while практически не отличимы по скорости
   • для перебора простых индексных массивов лучше использовать for или while
   • для перебора ассоциативных массивов лучше использовать foreach
   
   
   
2. preg_match('/a-zA-Z/i',$subject)...
   зачем здесь две группы символов, одну из них, a-z или A-Z, можно убрать, подумайте почему...
   А вот с символами кириллицы лучше именно так preg_match('/а-яА-Я/',$subject), потому что при корявой настройке локали на сервере php не различает строчные и прописные русские буквы, а при явном указании /а-яА-Я/ мы задаем диапазон кодов символов, поэтому функция будет работать как и ожидается (из-за локали также может не работать с кириллицей strtolower и strtoupper)
   
   
3. "Cannot send session cookie — headers already sent by… " — попытка установить куки, когда заголовок уже послан браузеру — не заметили пустую строку или пробел в начале файла
   
   
4. разнесение подключаемых с помощью require_once функций на множество мелких файлов не оправдано, php гораздо быстрее подключает один большой
   
   
5. echo "something $var something";... - медленно
   гораздо быстрее: echo 'something '.$var.' something';
   еще быстрее: echo 'something ',$var,' something';
   
   
6. if(mysql_query("select * from users where login='login' and pass='pass'",$db))
$auth = true; ...
   если запрос корректен, то он вернет true даже если ни одной строки не было выбрано. В подобных случаях нужно использовать mysql_num_rows
   
   
7. function len($str)
{ return strlen($str); }
   переписывание стандартных функций языка - зачем?
   
   
8. для чтения файла file() быстрее, чем fopen+цикл
   
   
9. разработка велась под windows, а хостинг на linux и сайт не поднимается — имя файла index.php, Index.php, INDEX.php и т.д. это все разные файлы для linux систем
   
   
10. PHP файлы с нестандартными расширениями (к примеру .inc вместо .php) — если не защитить такие файлы, то потом может быть очень стыдно, а лучше вообще их избегать
11. в рассчете на short_tags, поленились писать полностью — теперь на новом хостинге нужно переписывать шаблоны
    
    
12. слишком длинные имена переменных (8 и более символов) снижают быстродействие (не могу точно объяснить почему, но это факт)
    
    
13. реализация функционала БД средствами PHP — array_search вместо WHERE и другие чудеса незнания SQL, тут без комментариев
    
    

• Tweet

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

зачастую для ускорения работы ф-ии люди передают в нее ссылку на тот или иной элемент

function (& $varBig)
{ echo $varBig."<br>"; //как видим $varBig не изменяется }

Хочу сказать что это не оправдано так как php подерживает механизи "отложенного копирования" что означает что на самом деле и так передастся ссылка на элемент а не его копия.
(Я думаю сложно будет сейчас уже найти хост где используют настолько старый php где у него нет этого механихма)

Вывод: используйте передачу по ссылке если в ф-ии вам и вправду нужно будет изменить элемент.

недавно друг прислал мне статью по оптимизации программ на php вот ссылочка http://php.spb.ru/php/speed.html

С третьим не соглашусь. Часто бывают случаи что маленькими файлами подключаются разные функции, которые временами в целях отладки должны быть выключены. Проще закомментировать строку require_once чем комментить кусок кода в большом файле.

php подключает один большой файл БЫСТРЕЕ, чем много мелких несмотря на то, что где удобней комментировать

Автор, ты не объяснил почти ни один их пунктов! И вообще такое впечатление, что ты быдлокодер дошкольного возраста...

Вир, да, в школу я только на будущий год пойду. а вот если тебе для данных примеров требуются объяснения, то кто из нас \"быдлокодер\" это еще вопрос...

Вир - лось почтовый. и ниипет.

"php подключает один большой файл БЫСТРЕЕ" - наверное потому что web-сервер быстрее читает из одного файла, а не из многих? ;) Автор, спасибо за сайт. Некоторые статьи нашел для себя очень полезными. Такой вопрос(совет) - почему Вы не используете htmlspecialchars() при сохранении комментариев? У Вас же вот такие знаки \" < \' экранируются слэшами, да с ними и выводятся.. А с упомянутой функцией специальные символы преобразуются в HTML сущности и будет красиво..

Ой, оказывается используете.. Ну stripslashes тогда надо делать :)

Вот немного, так на вскидкУУУУ :) функции как echo медленней чем принт. print "tralala {$value}"; //самое медленное print "tralala $value"; print 'tralala '.$value; Лучше писать все в одном файле. Особо здоровые куски, можно инклюдить. формы, и т.д. сложнее для взлома, и наибыстрейшие время выполнения. Правдо вот чтото менять в таком коде сможете только Вы :) PS: для соеденения ключиков, запятыми, можно использовать implode(',',$keys) вместо цикла for по массиву с ключиками.

14. Используйте включения, когда это возможно: $a = <<< BUF <html> ... </html> BUF; вместо: $a = "<html> ... </html>";

modder from moddi.ru, сложно понять, какого именно мнения вы поддерживаетесь,- синтаксис и пунктуация есть в таком языке, как русский. ..и такой вопросик, давно интересовавший: Какой вид кавычек \"быстрее\" \" или \', сам я думаю что \', т.к. транслятор \"не будет искать\" в таких строках ссылки на переменные... как думаете вы?

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

По поводу регулярных и русской раскладки - юзаем а-яА-ЯёЁ не знаю как это по версиям правится или нет, но у меня именно так- "ё" не попадет в диапазон почему-то.

to Алексей Николаев: >не попадет в диапазон почему-то. Она (Ё/ё) в самой кодировке лежит вне диапазона А-Я/а-я.

По поводу ошибок. Грабли, на которые наступил давно - это четыре оператора подключения файла: include, require, include_once и require_once, соответственно. Создав файлик с функциями, принялся радостно подключать его include( 'file.php' ) везде, где это было необходимо. А так как некоторые файлы при работе подключали и 'file.php', и другие файлы, которые, в свою очередь, также подключали 'file.php', то итог был печален: множественное определение функций, возникшее из-за множественного включения. После этого последовало внимательное изучение документации.

Ваша экономия наносекунд превращает код в нечитаемый низкоуровневый говнокод.

Авторы и почти все комментаторы (кроме прорицателя Вира) - быдлокодеры

мне кажется те, кто так ругается, просто узнали в статье свой "стиль программирования" ...

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

Согласен насчет наносекунд :-)
А, вообще, автору респект за попытку и в аццтой всех гневнокритиков.

Действительно, есть ведь такие понятие как MVС, использование тех или иных фреймворков, ORM... вероятно подобный подход к архитекруте ИС менее производителен чем вылизанный, с точки зрения приведенных выше советов, скрипт... но читается и поддерживается в разы хуже... сейчас уже наступило то время, когда дешевле добавить еще один сервер в кластер, чем вылизывать код... разумеется всему есть предел :)

Я жую, и пока жую, почитываю разное: вдруг какие-то идеи интересные подвернутся. Комент Dekoo меня рассмешил. Фреймворки придуманы для того, чтобы дети не ломали себе голову над трудностями программирования. Но если б не дяди, которые создают различные библиотеки функций и ВЫЛИЗЫВАЮТ КОД, детям пришлось бы туго. Так что, каждому свое - кто-то создает технологии, а кто-то способен только на использование чужего. Подход "добавить еще один сервер в кластер" и сгребание кода с помощью бульдозера - это етод лентяев и бездарей.

Константин, вы смешите еще больше.
"Фреймворки придуманы для того, чтобы..", "дяди", "дети" :\ лол

"Так что, каждому свое - кто-то создает технологии, а кто-то способен только на использование чужого.", - c такой философией, почему бы вам не придумать свой PHP и использовать его? зачем использовать готовый велосипед, соберите свой!

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


to Автор: Неплохо было бы указать про "ловушки" cookie, а так же совет не увлекаться процедурщиной и изучать ООП

kolpeex 30.06.09 19:32

Ваша экономия наносекунд превращает код в нечитаемый низкоуровневый говнокод.



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

вот еще забыл добавить насчет читаемости: наберите что угодно в google и откройте исходный код странички. или, может, google вы тоже не уважаете?

гугл используют сжатие исходного кода. Если скопировать исходники гугл и отфомратировать в любой ide, получится вполне читаемый код

не соглашусь с 2... Между латинскими a и Z проскакивает нижнее подчеркивание.

Игорь
а я не соглашусь с вами, в данном случае i - игнорирование регистра, так что достаточно a-z или A-Z.

Алексей Николаев
Про русскую ёЁ - правильно, не стоит про это забывать.

Отличный сайт! Очень много всего интересного и полезного что использую на практике.

Насчёт п.12 (слишком длинные имена переменных (8 и более символов) снижают быстродействие (не могу точно объяснить почему, но это факт))

Это связано с отводимым колличеством байт на хранение имени переменной. Это место дискретно увеличивается: 8, 16, 32.. Получается, если использовать имя переменной до 8 символов, то их прочитать и работать с ними быстрее, чем с 16 или же с 32. Всё дело в адресации памяти:)

Тут реально все быдлокодеры. которым делать нечего (как и мне сейчас). 5-ый пункт убил. Эта статья выглядела бы адекватно, если были бы опубликованы тесты в виде:

1. Фрагмент кода с одним вариантом.
2. Фрагмент кода с другим вариантом.
3. Показано число вызовов или прогонов (тысячи или десятки тысяч, про микросекунды не очень интересно читать, ибо если они принципиальны, то скорее всего вам следует напиасать прогу, которая будет конвертировать ваш код из читабельного в убогий, но быстрый)
3. Времена выполнения обоих случаев (5-10 запусков).
Статья по первой ссылке не очень внятно всё это показывает.

ПС спасибо за сайт, много полезного материала, но эта статья - ололо какое-то, поржал.

- Использование ООП там, где это не нужно (классы замедляют работу, используют больше памяти);
- Ресурсоемкое преобразование данных, полученных из БД, при выводе (лучше преобразовывать в нужный для вывода формат при добавлении, поверьте, добавляют что-то значительно реже, чем просматривают, это снизит нагрузку);
- То, что обновляется примерно раз в час/день/месяц, например статистика за день, лучше кешировать (чтение из файла быстрее, чем из бд);
- Не используйте шаблонизаторы, дополнительные библиотеки без их надобности;
Немного не по теме: иногда, если вылетает ошибка, нужно найти ей объяснение в гугле. Чаще выдает не страницы с форумов о PHP, а как раз страницы, где эта ошибка вылетает и уже проиндексировалась:).

За год изучения пхп ни разу не спрашивал ничего на форумах, всё уже написано и объяснено, за что спасибо людям делающим подобные ресурсы.
К п.3 может можно добавить, что куки заполняются только после перезагрузки страницы. И пробел или перенос может оказаться в погружаемом до шапки файле функций пхп или ещё чего.

Спасибо, хорошая статья.

Поделюсь и я - над чем проломал голову около суток, Пусть другие не попадут.
Есть у меня куча функций для разбора объявлений по частям: www.najdu.ru (в цикле)
начал разбирать, какую часть можно оптимизировать, чтоб быстрее было
Никак не хотела одна из функций сокращаться во времени. Если весь цикл занимал 5 секунд, то 4 из них занимала эта функция.
Я все мозги себе слоамал, пока нашёл причину.
Не заметил, что внутри подгружённой require'ом функции есть ещё одна вставочка include. А теперь представьте каково это загружать полторы тысячи раз один и тот же файл. :)
И второе. Про SELECT тут уже сказано. А вот то что оказывается и UPDATE ! выдаёт true в любых ситуациях, когда запрос составлен верно. Т.е. даже если ни одного изменения сделано не было! Вот эта заковыка украла у меня добрые сутки времени.
Правда я использую mysql_affected_rows(). Только проблема в том, что она работает только при подключенном к базе состоянии. У кого-нибудь есть иное решение?

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

Про "купить сервер", "вылизать код" - код должен быть грамотно составлен с учетом расхода памяти и процессорного времени. Лишние траты того или иного делают код некачественным, а следовательно программиста не "хорошим" (как сказали выше, сравнивая стоимость программиста с сервером).
Сомневаюсь, что кто-то будет покупать вертолет только из-за того, что не может додуматься поехать коротким путем на автомобиле.

Вот из этого:
echo "something $var something";... - медленно
гораздо быстрее: echo 'something '.$var.' something';
еще быстрее: echo 'something ',$var,' something';
Знал только два первых способа, но не знал что они различаются по скорости!! Огромное спасибо за третий способ, проверил - работает.. Очень рад!!!
Еще такой вопрос - написали что
"tralala {$value}"; - самое медленное!
Но здесь по сути можно и не писать фигурных скобок!! Вот если бы так было - "tralala {$value[3]}"; тогда надо, либо вот так лучше - 'tralala ',$value[3],''; Сам вопрос же заключается в чем!! Как тогда в запросе mysql - записать вот это $x[3] без фигурных скобок (чтобы было быстрей)?? Если так mysql_query("SELECT ... `...` = '",$x[3],"' или '".$x[3]."' или = '.$x[3].' или ''.$x[3].'' ") не работает! Спасибо еще раз!!!

от кого: