- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
+100
Я на своем опыте заметил, что для WEB (простой сайт, новости, статьи, гостевуха, или даже блог) вообще не нужно ООП а исполняемые за раз скрипты в 99% случаях занимают 2-3кб
(при полной готовой к использованию CMS в 10-15кб не считая дизайна...)
По сути сайт (не сервис какой нибудь, а тупо информационный сайт) это лишь FrontEND для 2-3 таблиц БД
Тебе нужно вывести на страницу 10 записей из таблицы по одному шаблону. Ты же используешь функцию, правда? А если нужно вывести 2000 записей в разные блоки и в разные шаблоны? Ты напишешь например 2 функции, или 4, или 10. В то время как можно сделать полиморфный класс и уменьшить время выполнения процентов на 5-10, пусть пожертвовав немного памятью сервера. Нет, что ни говори, а ООП вещь хорошая, если используется с умом.
Во-первых - не стоит оптимизировать раньше времени. Если все работает нормально, то скрипт лучше вообще не трогать. Т.е. задачу оптимизации надо решать по мере поступления.
Вспомнился случай из жизни:
Клиент: а как оно работает?
Продавец: не знаю...
Клиент: можно исходный код посмотреть?
Продавец: не надо, а то мало ли потом перестанет...
ООП вещь хорошая, если используется с умом.
Да, если с умом то хорошая, но в WEB-программировании практически не нужная... (я говорю про сайты, а не какие-то сложные системы)
Реально имеет смысл оптимизировать алгоритмы а не выигрывать 0.00001 секунду заменяя count на sizeof. Если речь конечно идет именно о сайтах.
+1. И даже по еще 2 причинам.
а) Всякие zend optimizer-ы нередко сами заботятся о многих упомянутых вещах.
б) От версии к версии результаты бенчмаркинга бОльшей части упомянутых вещей могут менятся с точечностью до наоборот.
Если же это некое сложное web-приложение (например поисковая система), то там уже и экономия на спичках даст хороший вес.
0. Реально нагрузочные приложения выполнять на php грешно, их даже экономия на спичках не спасет. Для них есть c/c++, по крайней мере для узких мест, что кстати в статье упомянутой ТС в первом посте сказано.
По теме могу сказать, что очень хороший прирост производительности дает правильное использование ООП. Например взять тот же форум PHPbb - одни сплошные классы и в итоге весьма медлительный двигун.
Заблуждаетесь:) Классы это тормоза, как раз отказ от них дает хороший прирост производительности. "Классный" код по сравнению с функциями в пхп имеет честь занимать в 3-5 раз больше памяти и кушать в 2-3 раза больше процессорного времени при прочих равных. Так что уж из-за чего чего, а из-за производительности программинг на классах выбирать не стоит, для его выбора есть другие причины. Тестировали не раз и не два и по 4-ой версией и под 5-ой, так что для нас вывод однозначен.
По моему сугубому мнению, все эти шаманства с print/echo, for/foreach причем с отрывом от контекста задачи дают такой же выхлоп, как и гадание на кофейной гуще.
Во-первых - не стоит оптимизировать раньше времени. Если все работает нормально, то скрипт лучше вообще не трогать. Т.е. задачу оптимизации надо решать по мере поступления.
Второе - надо оптимизировать не функцию/оператор, а саму логику приложения. Если начало тормозить - ставим счетчики, замеряем время, ищем "подозрительный" кусок, и только тогда начинаем править.
Третье - чаще всего тормоза - это перенормализованные БД, кривые запросы к ней же, неэкономичные алгоритмы обходов, но никак не конкатенация и прочая мелочевка :)
+1
В целом не считаем что на php в прямом смысле есть задачи оптимизации скриптов как таковой. У нас вот 90% задач по "оптимизации" это исправление кривого кода, а не ускорение правильного в целом кода. Не можем представить себя сидящих и переписывающих $i++ на ++$i и на полном серьезе гордящимися результатом:)
Плюс есть еще один момент. Все эти "хитрости" они хороши если над проектом работает один человек, а вот если их несколько, то куда более важно сохранять единый стиль кода, относительно всем привычный и стандартный, а не выкраивать миллисекунды.
Реально нагрузочные приложения выполнять на php грешно, их даже экономия на спичках не спасет. Для них есть c/c++, по крайней мере для узких мест, что кстати в статье упомянутой ТС в первом посте сказано.
Нагрузочные на что? Я имею ввиду не фронт-енд, а бэк-енд, который используется для ручной корректировки поискового индекса. Я сам писал поисковик, который парсит раз в 12 часов 70 сайтов туроператоров, сгружает с них новые прайсы в XML/XLS, разбирает их, синонимизирует и после проверки оператором вносит в базу. И писать это на си не было никакой возможности по ряду технических причин. Вот тут использование всяких "фич" интерпретатора PHP дало бонус процентов в 20%.
Классы это тормоза, как раз отказ от них дает хороший прирост производительности. "Классный" код по сравнению с функциями в пхп имеет честь занимать в 3-5 раз больше памяти и кушать в 2-3 раза больше процессорного времени при прочих равных. Так что уж из-за чего чего, а из-за производительности программинг на классах выбирать не стоит, для его выбора есть другие причины.
Не совсем верно. Под каждый экземпляр класса конечно выделяется память, в отличие от инклюдов и функций, но что до процессорного времени - при многопоточности приложения (когда более 5-10 экземпляров одного класса используется в одном сеансе вызова апача) скорость обработки и выдачи данных классами (при грамотной структуре, конечно) больше чем аналогичный показатель для подпрограмм и инклюдов. Т.е. создание класса требует порядком процессорного времени, но в дальнейшем вызовы его методов проходят быстрее чем вызов подпрограмм, а уж тем более include
Я сам писал поисковик, который парсит раз в 12 часов 70 сайтов туроператоров, сгружает с них новые прайсы в XML/XLS, разбирает их, синонимизирует и после проверки оператором вносит в базу. И писать это на си не было никакой возможности по ряду технических причин.
Это не делает вам чести. Я бы такой поисковик просто отказался бы писать (если уж нет возможности написать его "нормально" то уж лучше никак чем "тяп-ляп")
Оптимизация, основанная на выборе тех или иных функций, мне кажется экономией на спичках. Сейчас гораздо проще купить более мощные железки/канал, чем тратить время на оптимизацию, которая даст копеечное ускорение.
Во, уверен, человек отлично бы влился в команду Microsoft. Работал бы над Vista 2.0, которая потребует всего лишь гигабайт тридцать места на винчестере и столько же оперативной памяти. Хороший подход! Современный.
Это из серии
void main() {
asm {
...
😂
Кстати, вот кое что из моих закладок:
21 ошибка программиста PHP. На мой взгляд, отличнейшая статья. Не раз возвращался к ней.
Полезные мелочи программирования на PHP. Тоже намотал на ус кое что.
40 советов по оптимизации вашего PHP-кода. Как обычно, на «хабре» комментарии иногда интереснее, чем сама заметка.
Во, уверен, человек отлично бы влился в команду Microsoft. Работал бы над Vista 2.0, которая потребует всего лишь гигабайт тридцать места на винчестере и столько же оперативной памяти. Хороший подход! Современный.
Да можно было бы это пережить, если бы то что они создали работало быстрее, чем ОС ниже класса, а получается оборот кушает много, но зачем... никто не знает 🙄