Когда оптимизация действительно стоит потраченного на нее времени?

Question

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

Стоит ли тратить 4 часа, чтобы запросы были на 20% быстрее? Да, нет, может быть, да, если ...?

Тратит ли 7 часов на переключение задачи на другой язык, чтобы сэкономить около 40% загрузки ЦП? Стоит ли это?

Моя обычная итерация для нового проекта:

1. Понять, что хочет клиент и что ему нужно;
2. Планирование проекта: какие языки и где, дизайн базы данных;
3. Разработка проекта;
4. Тест и исправление ошибки;
5. Финальный анализ работающего проекта и финальные оптимизации;
6. Если проект требует этого, дальнейший анализ реального использования ресурсов с последующей оптимизацией;

Подразумевается «Написать хороший, поддерживаемый код».

Очевидно, что большая часть «оптимизации» происходит в точке № 2, но часто при просмотре кода после завершения проекта я нахожу некоторые разделы, которые, даже если они хорошо выполняют свою работу, могут быть улучшены. Это обоснование для пункта № 5.

Чтобы привести конкретный пример последнего пункта, простой пример - когда я ожидаю, что 90% запросов будут SELECT, а 10% - INSERT/UPDATE, поэтому я беру таблицу БД с индексами. Но через 6 месяцев я вижу, что в реальной жизни есть 10% SELECT запросов и 90% INSERT/UPDATE с, поэтому скорость запросов не оптимизируется. Это первый пример, который мне приходит в голову (и, очевидно, это скорее «патч» для первоначального неправильного дизайна, чем для оптимизации;).

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

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

Когда вы думаете, что оптимизация имеет решающее значение?

Какую формулу вы обычно применяете, сознавая, что время, потраченное на оптимизацию (и конечный выигрыш), не всегда поддается количественной оценке на бумаге?

РЕДАКТИРОВАТЬ : извините, но я не могу принять ответ типа "пока люди не жалуются на id, оптимизация не нужна"; Это может быть бизнес-взгляд (сомнительный, imho), но не разработчик или (imho тоже) хороший ответ. Я знаю, этот вопрос действительно субъективен.

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

Спасибо всем;)

Answer 1

YAGNI . Если люди не жалуются, много.

---

РЕДАКТИРОВАТЬ : Я создал библиотеку, которая была немного медленнее, чем альтернативы. Он все еще набирал популярность и делился, потому что это было приятнее в использовании и мощнее. Я продолжал инвестировать в функции и возможности, откладывая любую работу на производительность.

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

Я думаю, что это правильный подход к этому.

Answer 2

Здесь есть (по крайней мере) две категории «эффективности», о которых следует упомянуть:

• приложений пользовательского интерфейса (и их зависимостей), где наиболее важной мерой является время отклика для пользователя .

• Пакетная обработка, где основным показателем является общее время работы .

---

В первом случае существуют хорошо документированные правила относительно времени ответа . Если вы заботитесь о качестве продукта, вам необходимо сократить время ответа. Чем короче, тем лучше, но переломные моменты примерно такие:

• 100 мс для «немедленного» ответа; анимация и другие действия в режиме реального времени должны происходить, по крайней мере, так быстро;

• 1 секунда для «непрерывного» ответа. Больше, чем это, и пользователи будут разочарованы; вам также нужно подумать о том, чтобы показать экран прогресса после этой точки.

• 10 секунд для сохранения фокуса пользователя. Хуже, чем этот, и ваши пользователи будут разозлены .

Если вы обнаружите, что некоторые операции занимают более 10 секунд, и вы можете исправить проблемы с производительностью с помощью вменяемого усилия (я не думаю, что есть жесткое ограничение, но лично я Я бы точно сказал что-нибудь до 1 человеко-месяца и, возможно, что-нибудь до 3-4 месяцев), тогда вы должны определенно приложить усилия для его исправления.

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

Но не принимайте решение исключительно на этой основе - опыт пользователя также имеет значение. Если вам потребуется 1 неделя, чтобы придерживаться некоторых диалогов асинхронного прогресса, и 3 недели, чтобы получить время выполнения менее 1 секунды, я все равно остановлюсь на последнем. ИМО, все, что меньше человеко-месяца, оправданно, если проблема касается всего приложения если это всего лишь один отчет, который запускается относительно редко, я бы, наверное, его отпустил.

Если ваше приложение работает в режиме реального времени - например, в графике - тогда я бы классифицировал его так же, как 10-секундную отметку для приложений не в реальном времени. То есть вам нужно сделать все возможное, чтобы ускорить его. Мерцание недопустимо в игре или в графическом редакторе. Заикания и глюки недопустимы при обработке звука. Даже для чего-то такого базового, как ввод текста, задержка в 500 мс между нажатием клавиши и появлением символа совершенно неприемлема, если вы не подключены через удаленный рабочий стол или что-то еще. Для решения подобных проблем не требуется слишком много усилий.

---

Теперь о втором случае, который, я думаю, в основном очевиден. Если вы выполняете пакетную обработку, то у вас обычно есть проблема масштабируемость . Пока партия может работать в отведенное время, вам не нужно ее улучшать. Но если ваши данные растут, если пакет должен работать в одночасье, и вы начинаете видеть, как он ползет в первые часы утра и прерывает работу людей в 9:15, тогда, очевидно, вам нужно работать над производительностью.

На самом деле, вы действительно не можете ждать так долго; как только он не завершится в нужное время, у вас могут возникнуть большие проблемы. Вы должны активно отслеживать ситуацию и поддерживать некоторый запас прочности - скажем, максимальное время работы 5 часов из доступных 6, прежде чем вы начнете беспокоиться.

Таким образом, ответ для пакетных процессов очевиден. У вас есть хард требование, чтобы баст должен закончиться в течение определенного времени. Поэтому, если вы приближаетесь к краю, производительность должна быть улучшена, независимо от того, насколько это трудно / дорого. Тогда возникает вопрос , что является наиболее экономичным средством улучшения процесса?

Если стоит просто добавить больше оборудования для решения проблемы (и вы точно знаете, что проблема действительно масштабируется вместе с оборудованием), не тратьте время на оптимизацию, просто купите новое оборудование. В противном случае, выясните, какая комбинация оптимизации дизайна и модернизации оборудования обеспечит вам наилучшую рентабельность инвестиций. На данный момент это почти чисто решение о стоимости.

---

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

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

Answer 3

Оптимизация того стоит, когда это необходимо.

Если мы пообещали клиенту время отклика при поиске праздничных пакетов, которое составляет 5 секунд или меньше, и что система будет работать на одном сервере Oracle (любой спецификации), а поиски занимают 30 секунд при пиковой нагрузке, оптимизация определенно стоит того, потому что иначе нам не заплатят.

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

Answer 4

Хороших постов всем.

Вы смотрели на ненужное использование транзакций для простых SELECT? Я несколько раз обжегся на этом ... Я также сделал некоторую очистку кода и обнаружил, что МНОГИЕ графики возвращаются, может быть, для 10 необходимых записей ... и так далее ... иногда это не ВАШ код как таковой, а кто-то вырезал углы .... удачи!

Answer 5

Как и все говорили в других вопросах, ответы таковы: когда есть смысл что-то менять, тогда это нужно менять. В большинстве случаев достаточно хорошо побеждает день. Если клиенты не жалуются, то это достаточно хорошо. Если они жалуются, исправьте это так, чтобы они перестали жаловаться. Agile методологии помогут вам узнать, когда достаточно. Кому интересно, если что-то использует ЦП на 40% больше, чем вы думаете, если оно работает, и клиенты довольны, то это достаточно хорошо. Это действительно просто, сделайте так, чтобы он работал и обслуживался, а затем ждите жалоб, которые, вероятно, никогда не придут.

Если бы то, о чем вы беспокоитесь, было действительно проблемой, НИ ОДИН никогда бы не начал использовать Java для создания критически важных приложений на стороне сервера. Или Python или Erlang или что-то еще, что не является C в этом отношении. И если бы они это сделали, ничего не было бы сделано в течение определенного периода времени, чтобы даже приобрести того первого клиента, которого вы так боитесь потерять. Вы заранее будете знать, что нужно что-то изменить, прежде чем это станет проблемой.

Answer 6

Использование Закон Амдала . Он показывает, какое общее улучшение происходит при оптимизации определенной части системы.

Также: Если это не сломано, не исправляйте это .

Answer 7

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

Обычно думают, что способ найти этот код - это измерение времени, потраченного функциями , но, на мой взгляд, это дает только подсказки - вам все равно придется играть детектива. , что приводит меня прямо к коду , это стеков . Вот пример 40-кратного ускорения, достигаемого путем обнаружения и исправления нескольких проблем. Другие пользователи SO сообщали о коэффициентах ускорения от 7 до 60, достигнутых без особых усилий. *

* (7x: Комментарий 1 . 60x: Комментарий 30 .)

Answer 8

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

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

Answer 9

Если клиент не видит необходимости в оптимизации производительности, то нет причин делать это.

Определение измеримых требований к производительности SLA с клиентом (т. Е. 95% запросов завершено менее чем за 2 секунды) ближе к началу проекта позволяет узнать, достигли ли вы этой цели, или если у вас есть больше оптимизации, чтобы сделать. Тестирование производительности при текущих и предполагаемых будущих нагрузках дает вам данные, необходимые для проверки соответствия SLA.