- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
нашел нужный кусок кода if($this->article->sectionid == 2)
2 это id категории, как сюда правильно вписать еще один id ?
Так можно? if($this->article->sectionid == 2,9)
Так можно?
Или, если много наберётся:
Спасибо, сработал первый вариант - второй белая страница
второй белая страница
Скобку в конце закрывающую) добавить.
Снова встал подобный вопрос - а как сюда добавить раздел?
Можно добавить бесконечное количество or. Главное в кавычки поместить не забудьте.
Уважаемые, не используйте приоритетные операторы || и && направо и налево. Это негативно влияет на стабильность и производительность. Вместо этого, лучше использовать or и and, в случае, если не нужно вызывать все операции сравнения.
Это негативно влияет на стабильность и производительность.
А можно подробностей?
Сколько времени потратится на анализ корректности расставленных скобочек при использовании or и and (ну.. и человеком, и интерпретатором, раз уж выигрыши считаем)?
Сравнимо ли время выигрыша со временем загрузки страницы.. или установки соединения? Или запроса в базу и дальнейшего разбора результата?
И самое главное, насколько очевиден результат операции - не думаю, что начинающий вебмастер (всё чаще вопросы от них), да иногда и опытный программист (ну, в другой области он опытный..) сможет предсказать (естественно, если знаешь - пояснить не сложно):
Стабильность и производительность? Вы на калькуляторе PHP сайты делаете? :D
LEOnidUKG, это всем известная практика. Я лично для себя выполнял много бенчамарков по миллион итераций. Поверьте, иногда банальная проверка через (!= null) добавляла +3000% к времени выполнения скрипта по сравнению с isset(). Это касается абсолютно всего кода, даже регулярных выражений. Например, регулярное выражение с модификатором U в 200% медленнее аналога без этого модификатора. Проблема в том, что используют функционал направо и налево. Задумывается ли кто-то что в echo лучше писать запятую ежели точку для объединения строки? Задумывается ли кто-то о строгой типизации? О проверки через === вместо ==? О запуске strpos перед preg_match или str_replace? Это ведь в большинстве случаев выгодно.
У меня недавно был заказ на оптимизацию самописной системы сайта недвижимости. 10000 хостов в сутки, а в 503 уходило по 5 раз на день. Проблема нашлась довольно быстро. Я включил показ E_ALL, и обнаружил большую кучу NOTICE. Обычно об NOTICE программист даже не догадывается. Только опытный программист додумается составить карту выполнения скрипта и проверить NOTICE. После исправления всех предупреждений, и улучшения синтаксиса (в том числе or вместо ||), поверхностной оптимизации архитектуры страница генерировалась за 70 миллисекунд вместо прошлых 800-1200. Разница очевидна. Остается догадываться сколько дыр еще я закрыл, добавив строгую фильтрацию входящих данных. И стоит заметить, никаких Nginx, никаких кешеров я не добавлял. Стоило только прислушаться к интерпретатору и к практике уже знающих людей.
Использование || вместо or, в некоторых случаях является серьезной ошибкой. Например, когда в качестве сравнения вызывается функция, которая оставляет за собою не обратимый след, например, $a === true || die(); когда создается переменная в операторе сравнения, например, (($a = $b) === 1) || (($a = $c) === 2)) (то-есть, даже если b === 1, в переменной a будет присвоено 2. Естественно, таких очевидных ошибок никто не делает. А не очевидных? Оператор сравнения, тернарный оператор вызывается тысячи раз за один цикл скрипта. Это далеко не оптимизация регулярных выражений, на которую всем действительно наплевать.
В итоге приходиться делать миллионы баг фиксов, платить тысячи на оптимизации, покупать мощные сервера. А легче ведь писать грамотно. Не правда ли? :) О вкусах и стилях не спорят. Но нужно задуматься. Почему одни системы работают быстро, стабильно, их не взламывают, а другие работают как их опущенные конкуренты.
Дальше читать не имеет смысла. Можете дальше думать в сферическом вакууме.
После 10 000 запросов в секунду от юзерей ваш сервер ляжет намертво и хоть из двух строчек код напишите. Там вебсервер ляжет. При 1 000 000 вам нужно будет создавать сеть из серверов. Так что сказки студентам рассказывайте о тестах и т.п.
Проблема нашлась довольно быстро. Я включил показ E_ALL, и обнаружил большую кучу NOTICE. Обычно об NOTICE программист даже не догадывается. Только опытный программист додумается составить карту выполнения скрипта и проверить NOTICE. После исправления всех предупреждений, и улучшения синтаксиса (в том числе or вместо ||), поверхностной оптимизации архитектуры страница генерировалась за 70 миллисекунд вместо прошлых 800-1200. Разница очевидна.
Про опытного промолчу.. достаточно подумать.
По сути - Notice в лог падают.. диск нагружают.. А какая доля из этого пришлась на or vs ||
p.s. специально для теоретиков
(
[1] => 2.714164018631 (and)
[2] => 2.2921290397644 (&&)
[3] => 2.6769030094147 (or)
[4] => 2.4104430675507 (||)
)
---------- Post added 26-04-2013 at 19:41 ----------
Замена 2-х строчек вначале (чтобы первое условие не выполнялось) особого преимущества также не даёт.
(
[1] => 2.5394430160522 (and)
[2] => 2.0652871131897 (&&)
[3] => 2.651880979538 (or)
[4] => 2.2204239368439 (||)
)
"обычный" хостинг от .m обычного хостера
---------- Post added 26-04-2013 at 19:56 ----------
Это ведь в большинстве случаев выгодно.
В каком, например..
Нет, мне правда интересно.
Задумывается ли кто-то что в echo лучше писать запятую ежели точку для объединения строки?
Если echo нужно писать через запятую, то скорее всего представление не отделено от логики..
А при отделении придётся точки ставить..
Несмотря на то, что "сама идея верная" (лучше писать код "правильно"), преподнести её получается не очень удачно.
Оптимизация нужна, но не использованием запятых вместо конкатенации..
Сначала искать узкие места = bottleneck-и, и им уделять внимание..
Естественно, если программа содержит кучу ошибок/предупреждений - их имеет смысл исправлять (хотя, подозреваю, что в данном конкретном случае отключение логирования "нотисов" помогло бы "значительно" ускорить сайт)
p.s. программы на ASM-е намного быстрее скриптовых языков.. может на них сайты писать?
p.p.s. извиняюсь за многотекста