Насколько важный оптимизация?

Инженер повсюду, оптимизируйте в конце.

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

Еще хуже, думая о "то, как я делаю X быстрый", может быть очень недовольным. К большому количеству энергии в том направлении может легко привести к Вам отсутствующий на методе Y, который намного лучше (и часто быстрее---это то, как "оптимизация" может сделать Ваш код медленнее). Особенно, если Вы делаете слишком многое из этого на большом проекте с начала, оно представляет большой импульс. Если Вы не можете позволить себе преодолеть тот импульс, можно легко стать заблокированными в плохой дизайн, потому что Вы не можете позволить себе время для реструктуризации его. Этот путь лежит драконы

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

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

[редактирование: фыркайте, конечно, кавычка Knuth инкапсулирует это хорошо. Это - то, что я получаю для ввода слишком много]

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

С 2 лет создания высоко оптимизированного кода Java (и это должно было быть оптимизировано тот путь) я скажу, что существует потраченное на время правило, которое управляет оптимизацией:

• оптимизация на месте: 5%-10% Вашего времени разработки, потому что необходимо сделать это бесчисленные времена (каждый раз необходимо исправить дизайн),
• оптимизация как раз в то самое время, когда у Вас был он работа: 2% Вашего времени разработки (Вы делаете это только однажды),
• возвращение к нему и оптимизация, когда это слишком медленно: 30% Вашего времени разработки, потому что необходимо погрузить себя назад в систему

ТАКИМ ОБРАЗОМ, я пришел бы к выводу, что существует правильное время и правильный способ оптимизировать: сделайте это объект объектом (класс классом, если у Вас есть классы, которые имеют единственное, четко определенное задание, чтобы сделать, и могут быть протестированы и оптимизированы), тест хорошо, удостоверьтесь, что логика работает, оптимизируйте просто позже и забудьте, о котором реализация объекта детализирует навсегда.

Я думаю, что "преждевременная оптимизация является корнем всего зла", должен быть понят буквально - это не говорит, когда преждевременно, и не говорит, что необходимо оптимизировать только в конце. Просто не слишком рано. Кроме того, "использование, правильный алгоритм, O (n^2) по сравнению с O (N)" немного опасен, если взято буквально - потому что для многих проблем, N является на самом деле маленьким и т.д...

Я думаю, что это во многом зависит типа программного обеспечения, которое Вы делаете: некоторое программное обеспечение таково как каждая часть, очень независимо, и может быть оптимизирован отдельно. Но это не всегда имеет место. Для многих (большинство?) приложения, скорость просто не имеет значения вообще, грубая сила, но очевидно исправляет путь, лучший. Но для проектов, где скорость имеет значение, она часто должна приниматься во внимание рано - возможно, это - другая возможная интерпретация высказывания Knuth: много приложений не должны быть оптимизированы вообще, просто знают, которые потребность и планирует заранее.

Я думаю, что код должен быть, прежде всего, читаемым и понятным. Так, оптимизации, которые сделаны, не должны быть за счет удобочитаемости. Однако оптимизация часто является компромиссом.

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

Однако преждевременная оптимизация не полезна, если Ваша система не была ясно spec'ed и поняла. Это вызвано тем, что большинство программистов не принимает хорошие решения оптимизации, если они не могут включить во влияние полной системы, включая процессор архитектурные факторы, такие как кэш-память, аппаратные потоки, конвейеры, и т.д.

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

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

Часто существует несколько способов сделать что-либо, необходимо выбрать в стадии проектирования ту, которая, скорее всего, выполнит лучшее (если это окажется одним из времен, когда это не является лучшим, затем оптимизируйте позже). Это должно превзойти потребность иметь легкий прочитать код.

Если Вы не рассматриваете производительность в стадии проектирования, Вы не собираетесь иметь хорошо разработанную систему. Это не означает, что должно быть единственное беспокойство (хотя в базе данных я оценил бы его как 3-й в важности, прямо после целостности данных и безопасности), но пытающийся зафиксировать систему, где плохо работающие методы использовались повсюду, потому что разработчики думали, что их было легче понять, кошмар. Быть пользователем такой системы, где необходимо ожидать в течение многих минут каждый раз, которые Вы хотите переместить от одного экрана до другого, является кошмаром (разработчики действительно должны тратить весь день каждый день, по крайней мере, в течение недели, с помощью их систем!) для всех, кто застревает с плохо разработанной системой. Это стоит меньше для разработки правильно, чем зафиксировать позже, и выполнение рассмотрения очень важно для разработки правильно.

Я работаю где-нибудь, где orginal разработчики выпили koolaid о преждевременной оптимизации и сделали все способ, которым они думали, было самым простым (но который почти в каждом случае был неправильным выбором с точки зрения производительности). Теперь мы в 10 раз размере, которым мы были три года назад, и каждый экран на каждом веб-сайте занимает приблизительно 30 секунд для загрузки (или худшие времена), и мы теряем клиентов из-за него. Но изменение его будет слишком трудно, потому что в основе они разработали базу данных, не рассматривая, как это будет работать и перепроектирование базы данных со многими, много гигабайтов данных в новую структуру являются слишком трудоемкими и дорогостоящими. Если бы это было разработано для выполнения от запуска, было бы и легче поддержать и быстрее для клиентов. Мы не говорим о потребности к мелодии производительности лучшие 10 самых медленных запросов здесь, мы говорим о том, что полная структура требует радикального изменения (тот, который влиял бы фактически на каждый запрос против системы) работать хорошо.

Да не делают микро оптимизации до Вас nmeed к, но сделайте макро-материал. Рассмотрите, ли это лучший способ перед согласием на путь. Не пишите курсоры для удара таблиц миллионами записей, когда основанный на наборе оператор сделает. Не пытайтесь иметь как можно меньше таблиц becasue, который, кажется, более изящное решение, когда таблицы хранят разрозненные объекты (такие как люди, места и механизмы) то, чтобы заставлять каждый запрос поразить ту же таблицу и порождение каждый удалять для проверки всех видов таблиц внешнего ключа, которые никогда не будут иметь записи для того типа объекта (требуются минуты для удаления одной записи из основной таблицы в нашей базе данных, это - реальная радость, когда что-то идет не так, как надо в импорте (неправильные данные от клиента обычно), и мы должны удалить 200,000, позволяют мне сказать Вам).

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

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

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

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

Если USP Вашего программного обеспечения - то, что это быстрее, чем Ваши конкуренты, то оптимизация является первоочередной задачей. С опытом можно часто предсказывать, какие виды операций будут узкими местами, разработают тех который имеют оптимизацию в памяти с самого начала, и более или менее проигнорирует оптимизацию в другом месте. Для большого количества проектов не будет даже нужно это: они будут достаточно быстры без особых усилий, если Вы используете разумные алгоритмы и не делаете ничего глупого. "Не делайте, что-либо глупое" всегда является первоочередной задачей без потребности упомянуть производительность в частности.

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

2. Периодически, стресс-тест с набором больших данных, представляя или (моя любимая техника) ручная случайная выборка. Вы находите проблему, Вы фиксируете ее. Вы находите другого, Вы фиксируете его.

Тем путем Вы стараетесь не создавать краткие заголовки (ошибки замедления), и когда они действительно возникают, Вы уничтожаете их.

Добавленный: Если я могу просто уточнить точку 1. OO является по-видимому законодательством страны, и оно, конечно, имеет серьезные основания позади него. К сожалению, это заставляет многих молодых программистов чувствовать, что программирование - все о наличии большой структуры данных со слоями на слои абстракции. Не то, чтобы это по сути плохо, но объединение, что с естественным стремлением, чтобы предположить, что время что-то взятия примерно пропорционально количеству символов, которые необходимо ввести для вызова его, и что эта тенденция умножается по слоям (и кроме того, машины действительно быстры), легко создать идеальный шторм отходов цикла.

Преждевременная оптимизация является корнем всего зла... Существует точная настройка между, но я сказал бы, что 95% времени необходимо оптимизировать в конце; однако, существуют решения, которые можно принять вначале, чтобы помочь предотвратить проблемы. Например, предположите, что мы говорим о веб-сайте электронной коммерции. У Вас есть требование для отображения каталога. Теперь можно захватить все 100 000 объектов и отобразить 50 из них, или можно захватить всего 50 от базы данных. Подобные решения должны быть приняты честные.

Подсчет цикла должен только быть сделан, когда проблема была определена.

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

Однако OP является правильным, что подсчет циклов бессмыслен для многих проектов. Для большинства приложений ПК ЦП никогда не является узким местом. Кроме того, IA32 не последователен - что работало хорошо над одной архитектурой, работает плохо на другом. Подсчет цикла должен только когда-либо делаться, когда это будет на самом деле иметь значение - обычно в ЦП ограниченный код или код с очень определенными потребностями синхронизации.

Оптимизация, любого вида, должна всегда управляться веским доказательством. Никогда ничего не принимайте о системе или как код ведет себя. В идеальном мире производительность приложения / ограничения будут указаны в начальном дизайне продукта, и инструменты для контроля производительности приложения во время разработки будут добавлены вначале в этапе разработки для руководства программистов, поскольку продукт сделан.