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

Question

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

Например, когда исправление сокращает среднее время ответа от 100 мс до 90 мс при некоторых условиях, следует ли мне внедрить это исправление? Что если он укорачивается от 200 до 190 мс? Сколько условий я должен попробовать, прежде чем я могу сделать вывод, что это будет полезно в целом?

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

РЕДАКТИРОВАТЬ: Спасибо за отличные ответы! Я полагаю, что мораль этой истории в том, что не существует простого способа определить, следует ли вам это делать, но есть НАПРАВЛЕНИЯ, которые могут помочь в этом процессе. Реализация исправления, даже если она сделала несколько строк кода в 20-30 строк кода. Потому что наше приложение. очень критичен к производительности, и в различных реалистичных случаях это был постоянный прирост в 10%.

Answer 1

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

«Преимущество достаточно велико» чрезвычайно субъективно. Можете ли вы или ваш работодатель продать больше единиц программного обеспечения, если вы сделаете это изменение? Будет ли ваша пользовательская база уведомлена? Это даст вам личное удовольствие иметь самый быстрый код? Какие из этих или подобных вопросов применимы только для вас.

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

Answer 2

Я думаю, что эмпирическое правило (по крайней мере, для меня) состоит из двух частей:

1. «Имеет значение, если это имеет значение» - в деловом мире это обычно означает, что оно имеет значение, есликлиенты заботятся.То есть, если конечные пользователи «заметят» разницу между 100 мс и 90 мс (я здесь не оскорбляю), то это имеет значение.
2. Если «это имеет значение», тогда вы захотите проверить своитщательно кодируйте против реалистичного разнообразия вариантов использования, которые могут возникнуть или, по крайней мере, могут возникнуть.Если оптимизация ускоряет выполнение кода в 50% случаев, но на самом деле работает медленнее, чем в предыдущие 50% случаев, очевидно, что это не стоит реализовывать.

Относительно пункта 1выше: предполагая, что конечный пользователь вашего программного обеспечения может «заметить» разницу в 10 мс, я не имею в виду, что они действительно заметят разницу.Но если ваше приложение работает на сервере с миллионами соединений, и каждое небольшое увеличение скорости отнимает значительную нагрузку на сервер, это может иметь значение для клиента, работающего на сервере.Или, если ваше приложение выполняет чрезвычайно критичную по времени работу, это еще один случай, когда результат ускорения в 10 мс может быть заметным, даже если само ускорение не так.

Answer 3

Дональд Кнут сделал следующие два утверждения об оптимизации:

«Мы должны забыть о маленьком эффективность, скажем, около 97% время: преждевременная оптимизация корень зла "[2]

и

"В устоявшейся технике дисциплинирует улучшение на 12%, легко получается, никогда не считается маргинальным и я верю в ту же точку зрения должно преобладать в программном обеспечении инжиниринг »[5]

Источник: http://en.wikipedia.org/wiki/Program_optimization

Answer 4

Вы должны сосредоточить усилия по оптимизации на тех частях кода, на которые приходится больше всего времени выполнения.Если определенный фрагмент кода занимает 80% от общего времени выполнения, то его оптимизация для сокращения времени на 5% окажет такое же влияние, как и сокращение времени остальной части кода на 20%.1002 * В целом, оптимизация делает код менее читабельным (не всегда, но часто).Поэтому вам следует избегать оптимизации до тех пор, пока вы не будете уверены в наличии проблемы.

Answer 5

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

Answer 6

Если выигрыш в производительности невелик, рассмотрите другие факторы: ремонтопригодность, риск внесения изменений, понятность и т. Д. Если это снижает способность поддерживать или понимать код, это, вероятно, не стоит делать. Если это улучшит эти атрибуты, тогда это еще одна причина для внедрения изменения.

Answer 7

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

Answer 8

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

Если код НАМНОГО сложнее понять.

Кроме того, 100мс до 90 мс - увеличение производительности на 10%.Усиление в 10% не следует воспринимать легкомысленно.

Реальный вопрос в том, что если для начала потребовалось всего 100 мс, какой смысл пытаться оптимизировать его?

Answer 9

Очень сильно зависит от сценария использования. Здесь я предполагаю, что рассматриваемый код был профилирован, и, таким образом, он является узким местом - т.е. не только «это может быть быстрее», но и «программа даст результаты / завершит работу быстрее, если это будет быстрее». В ситуациях, когда это не так - например, если вы тратите 99% своего времени на ожидание получения большего количества данных через соединение Ethernet - тогда вам следует позаботиться о корректности, но не оптимизировать по скорости.

• Если вы пишете фрагмент кода пользовательского интерфейса, то вам важна воспринимаемая скорость. Обычно все, что меньше ~ 100 мс, воспринимается как «мгновенное» - нет смысла его ускорять.
• Если вы пишете кусок кода для гигантской серверной фермы, то, если стоимость вашей зарплаты для быстрого создания кода меньше, чем стоимость дополнительного электричества для серверной фермы, это того стоит. (Но не забудьте расставить приоритеты.)
• Если вы пишете фрагмент кода, который используется редко или без присмотра, до тех пор, пока он завершается в полусмысленном периоде, не беспокойтесь об этом. Сценарии установки, как правило, относятся к этому типу (если только вы не начнете работать в течение нескольких минут, в этот момент пользователи могут отказаться от установки, поскольку она занимает слишком много времени).
• Если вы пишете код для автоматизации задачи для кого-то другого, то если (ваше время, потраченное на кодирование + время, потраченное на использование оптимизированного кода) меньше (их время, потраченное на медленный код), это того стоит. Если вы делаете это в коммерческих условиях, взвесьте это на соответствующую зарплату.
• Если вы пишете библиотечный код, который будет использоваться многими тысячами людей, всегда делайте это быстрее, если у вас есть время.
• Если вам не хватает времени, чтобы просто что-то заработало, например в качестве демонстрации не оптимизируйте (за исключением разумного выбора алгоритмов из библиотек), если только результат не будет настолько медленным, что он даже не «работает».

Одна из самых больших неприятностей для меня лично заключается в поиске программного обеспечения, которое, возможно, первоначально попало в одну категорию, а затем попало в другую, но для которой никто не вернулся для выполнения необходимых оптимизаций. До недавнего времени исполнение Javascript было отличным примером этого. Мораль этой истории такова: не просто решайте один раз; вернуться к вопросу, как того требует ситуация.

Answer 10

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