оптимизация

[domino]

всем привет. возник вопрос - так ли важна оптимизация?
речь не о том, чтобы писать бездарный быдлокод, а о том, что мощность железа и огромные объёмы памяти позволяют не гонятся за микрооптимизацией, в духе sizeof вместо count или
(пример с хабра)

 if (strlen($foo) < 5) { echo "Foo is too short"; }
медленне чем 
if (!isset($foo{5})) { echo "Foo is too short"; }

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

что вы думаете? какую оптимизацию стоит использовать? на что вы обращаете внимание, когда нужно повысить производительность кода? оптимизацию алгоритма в рассчёт не берём. это итак понятно.

 

[fStrange]

вы сами и ответили на вопрос.

Если решаете задачу, то зачем оптимизировать решение если оно работоспособно?
Кроме того маловероятно, что "узким местом" в коде окажется strlen($foo).

 

[Духовность™]

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

+100

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

Вот сейчас я подсчитал ради интереса - 65 подгрузок классов и их исполнение на ВИРТУАЛЬНОМ сервере (за 150 рублей/месяц) с 4 SQL запросами (кэшированными) выполняется в среднем 0.05 секунд.

 

[Adelf]

за такую оптимизацию надо карандашом по пальцам.

 

[dimagolov]

классы классам рознь. узким местом может быть не тяжелая, а как раз "быстрая" операция, если она выполняется очень часто. например, кастомный класс строки, если он используется всегда. лично я всупал в грабли с кастомный enum на php, когда переводил с С парсер RTF от мелкомягких, там конечный автомат и они использовались для всех состояний и создовались/менялись по несколько раз на каждом шаге, а это для каждого символа.

 

[HraKK]

Тезис №1
Преждевременная оптимизация корень всех бед.

Если Вы никогда не делали аналогичный highload проект, Вы НИКОГДА не скажите где у Вас будет узкое место, а посему я ( и такое классики как Фаулер, например ) советую Вам не оптимизировать заранее. Это не значит, что можно писать криво, наоборот делайте все правильно, красиво, гибко. Использование ООП и Design Patterns (шаблонны проектирования), только поощряются, а не как многие заблуждаюсь, советуют наоборот. Сейчас мы рассмотрим почему.
Раньше, дела обстояли так, что не было OP cache программ (те кто берут php код и сохраняют его результат интерпретации в кэше), что приводило к тому что интерпретация большого кода (а ООП код всегда несет в себе излишество) существенно замедляла отдачу. Теперь же есть много таких программ, я лично считаю лучшей бесплатную Xcache (которую, кстати, начинают ставить даже на простых хостингах).
Дальше, вспоминая 1 тезис, мы не знаем где будет узкое место, а когда сделали проект и увидели под реальной загрузкой что в таком-то месте у нас тормозит ( для этого можно например погонять в Xdebug) то мы всегда может сделать хак который ускорит это место убрав оттуда ООП или другой код внедрив или дополнительный кэш этого места. Всегда можно от высокого спустится к низшему. А, ухудшая изначально свой код, Вы делаете непоправимое - скоро крупный проект выйдет у Вас из под контроля и Вам придется переписывать заново его или мучаться с поддержкой этого жиле.

(с)http://correct.com.ua/ru/interesting/highload

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

 

[Духовность™]

Какое резюме не возьми везде опыт хайлоада, а что такое инкапсуляция не знают.

За%бали да, работодатели. Какую вакансию не возьмёшь, везде опыт хайлоада нужен. Вот и пишут видать

 

[DYPA]

хм, в одном проекте было что тормозила конструкция

list($a, $b) = explode('blabla', $array);

но так вызовов было порядка 20к на приложение её...
тормозит обычна кривая архитектура, и тормозит только по тому что трудно переписать на нормальную
зы то что реально можно оптимизировать - так это использование __get, __set, __call и тд просто отказавшись от их использования где это можно (прирост от 4х условных попугаев)
зыы всё что выполняется меньше 0.5 сек можно не оптимизировать, но при условии что канал до клиента хороший и браузер не тратит на рендер более 0.5 сек

 

[DYPA]

За%бали да, работодатели. Какую вакансию не возьмёшь, везде опыт хайлоада нужен. Вот и пишут видать

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

 

[WDStalker]

В вопросах оптимизации всегда боюсь циклов и регулярных выражений. Если есть возможность, то циклы уменьшаю до мин и отказываюсь от регулярных выражений.
А все остальное по скорости ничего не решает, как я думаю.
Конечно есть еще куча нюансов, но это уже с опытом. Не задумываешься когда пишешь.

 

[fixxxer]

А двойные кавычки на одинарные заменяешь?

 

[fixxxer]

Теория, #&^#%, программирования, my ass.

 

[WDStalker]

А двойные кавычки на одинарные заменяешь?

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

 

[fixxxer]

А в чужом коде?

 

[WDStalker]

А в чужом коде?

в мазохисты не записывался.
Как говорит мой автомеханик, зачем лезть в отлаженный механизм???

 

[Активист]

Имхо, лучшая оптимизация кода - это нихрена не обрабатывать на стороне серверов, отдать весь или практически весь рендеринг пользователю, средвами JS, Ajax и т.п., а работу всей системы свести к "входные данные -> валидация -> сохранение" и "проверка доступа -> вывод сохраненных данных", ресайз фоток и другие ресурсоемкие операции отдать пользователю, через те же, например Flash Uploader, JRE и т.п.

Ушло в офтопик

 

[zerkms]

Активист
Тогда предлагаю все сайты делать просто в виде открытой PMA, rw-доступ без пароля. А пользователи пусть сами там выбирают чо надо

 

[Активист]

Зачем крайности?

 

[DYPA]

Юмористы Предлагаю развить идею и сократить серверный код до exit

хм, а почему бы и нет, вон на чистом couchdb люди пишут же js приложения

 

[Активист]

Давно прошли времена, когда сервера были мощнее рабочих станций, сейчас сервера зачастую бывают ниже по производительности некоторых рабочих станций, так например, есть те кто фапают на VIP, покупая самое лучшее только потому что фапают, возьмем в эту касту дрочеров - там вообще, как только процы выходят новые - тут же приобретают не доедая но с ЧСВ, так вот, у них колоссальные вычислительные мощности тупо простаивают и это просекли британские ученные, создав единую сеть систем анализа белковых соединений, реклама которой идет по вирусному принципу, они предлагают установить софт, само собой под предлогом спасения мира (о дальнешем профите владельцев не слова), который обрабатывает данные, пока юзер гоняет косынку или читает соцсеть, объединив уже миллионы (а то и больше) компов, они добились таких вычислительных мощностей, что любой ЦОД позавидует.

Сейчас можно практически любую отрисовку, рендеринг, обработку (под обработкой понимается - трансформация данных и приведения их к нужному формату) данных отдать на на сторону клиента, а на серверной части отдавать читый exit c json результатом, к примеру, а как его браузер это отрисует, проблема самого юзера. Задача серверов (кластера в целом) должна сводиться к приему данных, их проверки на валидность и права, сохранение, отдача же должна происходить без каких либо доп. проверок, только проверка на права доступа, статика должна кешироваться на стороне клиента и это нужно проверять.