- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
С Днем Победы!
Предлагаю создать FAQ по оптимизации PHP-скриптов.
Будем делиться своими советами и наблюдениями по быстродействию тех или иных функций и по их использованию.
Побудило меня создать эту тему использование циклов (for, foreach, while) - они работают с разной скоростью, но какой быстрее? Читал, что foreach самый медленный, но при тесте на локалхосте оказалось, что while. Правда, у меня тогда апач глючил. Всё же, какой из циклов самый быстрый и самый медлительный?
Не будем повторять то, что уже написано здесь (english) и здесь (russian).
P.S.: обфускаторы и зендеры не в счёт :)
Убийство цикла for - слишком многа букаф
о циклах. В основном, о for
Оптимизация, основанная на выборе тех или иных функций, мне кажется экономией на спичках. Сейчас гораздо проще купить более мощные железки/канал, чем тратить время на оптимизацию, которая даст копеечное ускорение.
А если уж гнаться за скоростью во всем, то проще вообще отказаться от похапе.
Оптимизация, основанная на выборе тех или иных функций, мне кажется экономией на спичках. Сейчас гораздо проще купить более мощные железки/канал, чем тратить время на оптимизацию, которая даст копеечное ускорение.
А если уж гнаться за скоростью во всем, то проще вообще отказаться от похапе.
Есть такая пословица "Копейка рубль бережет" :)
Когда запросов к скрипту становится много (рост посещаемости), а приобретение собственного сервера является не рентабельным для данного сайта (скрипта), тогда начинаешь задумываться об оптимизации тех или иных функций. И порой грамотное использование выбранного языка, позволяет значительно экономить на железе 🚬
armsites, Вы не правы.. тут о другом речь ;)
Я считаю, что следует использовать циклы по их прямому предназначению: for для исполнения действий, которые требуют некоторое число, изменяемое с определенным шагом, (спорно) также для итерации numeric массивов; foreach для итерирования над объектом (включая массивы); while в остальных случаях. Особого различия в производительности как минимум в PHP нет.
Но опять же.
Одно дело
- здесь в принципе можно использовать любой цикл, как удобнее. (Само собой надо делать поправку на ассоциативные массивы и в общем случае правильнее было бы использовать foreach() или даже foreach($array as $key=>&$value), чтобы не плодить лишние данные).
Но допускать такие вещи
вместо
конечно же нельзя в серьезных скриптах, которым и так есть, на что потратить процессорное время и время доступа к НЖМД.
Во всем остальном примерно также. Надо использовать возможности языка ради их прямого назначения, а не писать конструкции вида while($i++){if($i<10){}else{break;}} - ведь это идиотизм в общем случае.
ИМХО.
но при тесте на локалхосте оказалось, что while. Правда, у меня тогда апач глючил.
Вот интересно какая зависимость от выдачи апача, и собственно производительности цикла в пхп?
Может я что то туплю?
или Вы просто тестировали выдачу в браузер и на вскидку время чтоли определяли?
Есть такая вещь - inner loop, раскрытие цикла с целью оптимизации по скорости выполнения, но в php такого рода оптимизация, на мой взгляд, не оправдана. Области применения for, while и foreach давно определены и освоены. Оптимизировать же нужно запросы к MySQL как наиболее ресурсоёмкие вещи.
это про чо?
...повторяемся...
Это вообще не в тему.
Вообще я почти со всем там согласен, только мразматично так оптимизировать скрипты. Лучше оптимизировать алгоритмы, при правильном подходе это гораздо более продуктивно (по отношению время/качество).
Ну а если уж руки из Ж растут, то тут ни то не другое не помогет :)
Николай В., а если делаешь продукт для людей и он не оптимизирован, то что, говорить им: "Покупайте более мощное железо! Не буду я оптимизировать код!"
armsites,
1. Забудьте про поисковики! Делайте сайт для людей, а не для поисковиков!
2. Большинство хороших программистов знакомо с SEO, так что не надо "гнуть палку", что мы "неграмотны".
fleyg, у меня тогда весь комп глючил, а апач был в этом виной. Просто, ради интереса запустил цикл for($i = 0; $i < 100000000; $i++) {...} с user_abort (вроде так пишется) в false. Но, возможно, я не прав :-[ Serge_N, а если пишешь CMS на файлах и без БД, то что, и оптимизировать не надо? :)
это про чо?
1. На сколько я понимаю, require_once хуже, чем include_once.
2. error_reporting || display_errors
Лучше оптимизировать алгоритмы, при правильном подходе это гораздо более продуктивно (по отношению время/качество).
Оптимизировать алгоритмы - значит не сильно изменять код, т.е. оптимизировать код алгоритмов;
Менять алгоритмы - полностью изменять алгоритмы на более быстрые.
;)
1. На сколько я понимаю, require_once хуже, чем include_once.
Мда. Вот об этом я и говорил.
В названии функции заложено ее предназначение, а вы пишете хуже-лучше...
include_once (include=включить) - это включить код файла, при отсутствии файла вывести warning, скрипт не останавливать, повторно файл не включать.
require_once (require=требовать) - это включить код файла, при отсутствии файла вывести fatal error, скрипт остановить, повторно файл не включать.
Всё.
an0nym, буду знать. Спасибо :)