Когда увеличение производительности является достаточно значительным для реализации той оптимизации?
после учебника я действительно измеряю уровень каждый раз, когда я пытаюсь оптимизировать свой код. Иногда, однако, увеличение производительности является довольно маленьким, и я не могу решительно решить, должен ли я реализовать ту оптимизацию.
Например, когда фиксация сокращает среднее время отклика 100 мс к 90 мс при некоторых условиях, я должен реализовать ту фиксацию? Что, если это сокращает 200 мс к 190 мс? Сколько условия я должен попробовать, прежде чем я смогу прийти к заключению, что это будет выгодно в целом?
Я предполагаю, что не возможно дать прямой ответ на это, поскольку это зависит от слишком многих вещей, но является там хорошим эмпирическим правилом, за которым я должен следовать? Есть ли какая-либо инструкция/лучшие практики?
Править: Спасибо за большие ответы! Я предполагаю, что мораль истории, нет никакого простого способа сказать, должны ли Вы, но СУЩЕСТВУЮТ инструкции, которые могут помочь тому процессу.. Вещи, которые необходимо рассмотреть, вещи, которые Вы не должны делать и т.д. На этот раз я закончил тем, что реализовал фиксацию, даже при том, что она превратила некоторых строка кода в 20-30 строк кода. Поскольку наше приложение. очень очень важная производительность, и это было последовательное 10%-е усиление в различных реалистических случаях.
10 ответов
Я думаю, что эмпирическое правило (по крайней мере, для меня) - два -fold:
- «Это имеет значение, если это имеет значение» - в деловом мире это обычно означает, что важно, заботятся ли клиенты. То есть, если конечные пользователи «заметят» разницу между 100 мс и 90 мс (я не шучу здесь), то это имеет значение.
- Если «это имеет значение», то вы захотите тщательно протестировать свой код на реалистичном разнообразии вариантов использования, которые могут возникнуть или, по крайней мере, могут возникнуть . Если оптимизация ускоряет код в 50% случаев, но на самом деле выполняется медленнее, чем то, что у вас было раньше в остальные 50% случаев, очевидно, что ее, возможно, не стоит реализовывать.
Что касается пункта 1 выше: предполагая, что конечный пользователь вашего программного обеспечения может «заметить» разницу в 10 мс, я не хочу сказать, что они действительно заметят разницу. Но если ваше приложение работает на сервере с миллионами подключений, и каждое небольшое увеличение скорости значительно снижает нагрузку на сервер, это может иметь значение для клиента, на котором запущен сервер. Или, если ваше приложение выполняет чрезвычайно критичную по времени работу, это еще один случай, когда результат ускорения на 10 мс может быть заметен, даже если само ускорение не будет.
Вам следует сосредоточить усилия по оптимизации на тех частях кода, на которые приходится больше всего времени выполнения. Если конкретный фрагмент кода занимает 80% от общего времени выполнения, то его оптимизация для сокращения времени выполнения на 5% будет иметь такое же влияние, как и сокращение времени остальной части кода на 20%.
В целом оптимизация делает код менее читаемым (не всегда, но часто). Поэтому вам следует избегать оптимизации, пока вы не будете уверены в наличии проблемы.
Дональд Кнут сделал следующие два заявления об оптимизации:
«Мы должны забыть о небольшой эффективности, скажем, около 97% времени: преждевременная оптимизация - это корень всего зло "[2]
и
" В устоявшихся инженерных дисциплинах легко достижимое улучшение на 12%, никогда не считается незначительным , и я считаю, что такая же точка зрения должен преобладать в разработке программного обеспечения "[5]
Если прирост производительности невелик, рассмотрите другие факторы: ремонтопригодность, риск внесения изменений, понятность и т. Д. разобраться в коде, наверное, не стоит. Если он улучшит эти атрибуты, то появится больше причин для внесения изменений.
Если это вообще ускоряет вашу программу, почему бы не реализовать ее? Вы уже выполнили работу по созданию новой реализации, поэтому вы не делаете дополнительной работы, применяя новую реализацию.
Если только код не настолько сложен для понимания.
Кроме того, от 100 до 90 мс увеличивается производительность на 10%. К увеличению на 10% нельзя относиться легкомысленно.
Настоящий вопрос в том, что если для запуска потребовалось всего 100 мс, какой смысл в попытках его оптимизировать?
Единственный разумный подход к вашему вопросу - это что-то вроде «когда выгода достаточно велика, чтобы гарантировать время, которое вы вкладываете в изучение, внедрение и тестирование. оптимизация ».
« Выгода достаточно велика »крайне субъективна. Сможете ли вы или ваш работодатель продать больше единиц программного обеспечения, если внесете это изменение? Заметит ли ваша пользовательская база? Принесет ли вам личное удовольствие иметь максимально быстрый код? Какой из этих или похожих вопросов применим, - знать только вы.
По большому счету, большая часть программного обеспечения, которое я написал (за 20 с лишним лет карьеры), была «достаточно быстрой» из коробки, и код, который я старался оптимизировать, представлял собой очевидное узкое место для конечных пользователей. : Запросы, занимающие много времени, слишком медленная прокрутка и тому подобное.
- Не слишком ли оптимизация запутывает ваш код?
- Вам действительно нужна оптимизация? если ваше приложение работает нормально, то, вероятно, важнее удобочитаемость кода
- Работали ли вы над общим дизайном и алгоритмами своего приложения, прежде чем пробовать небольшие хитрые оптимизации?
Пока это достаточно быстро , вам больше не нужно оптимизировать. Но тогда вы бы даже не потрудились профилировать, если бы это было так ...
Это очень сильно зависит от сценария использования. Здесь я предполагаю, что рассматриваемый код был профилирован и, следовательно, известен как узкое место, т.е. не просто «это могло бы быть быстрее», но «программа дала бы результаты / завершила бы работу быстрее, если бы это было быстрее». В ситуациях, когда это не так - например, Если вы тратите 99% своего времени на ожидание поступления дополнительных данных по Ethernet-соединению - тогда вам следует заботиться о правильности, но не оптимизировать скорость.
- Если вы пишете фрагмент кода пользовательского интерфейса, вас волнует воспринимаемая скорость. Обычно все, что меньше ~ 100 мс, воспринимается как "мгновенное" - нет смысла его ускорять.
- Если вы пишете фрагмент кода для гигантской серверной фермы, то, если стоимость вашей зарплаты для быстрого выполнения кода меньше, чем стоимость дополнительного электричества для серверной фермы, это того стоит. (Но не забудьте расставить приоритеты со своим временем.)
- Если вы пишете фрагмент кода, который используется редко или без присмотра, если он завершается за полусредний период, не беспокойтесь об этом. Сценарии установки, как правило, относятся к этому типу (если вы не начнете работать в течение нескольких минут, после чего пользователи могут начать отказываться от установки, потому что она занимает слишком много времени).
- Если вы пишете код для автоматизации задачи для кого-то еще, то, если (ваше время, потраченное на кодирование + их время, потраченное на использование оптимизированного кода), меньше (их времени, потраченного на использование медленного кода), это того стоит. Если вы делаете это в коммерческой среде, взвесьте это с учетом вашей заработной платы.
- Если вы пишете код библиотеки, который будет использоваться многими тысячами людей, всегда делайте это быстрее, если у вас есть время.
- Если у вас мало времени, чтобы просто что-то работало, например в качестве демонстрации не оптимизируйте (за исключением разумного выбора алгоритмов из библиотек), если результат не будет настолько медленным, что он даже не «работает».
Одно из самых больших неудобств для меня лично - это поиск программного обеспечения, которое, возможно, сначала попало в одну категорию, а затем попало в другую, но для которого никто не вернулся, чтобы провести необходимую оптимизацию. До недавнего времени отличным примером этого была производительность Javascript. Мораль этой истории такова: не принимайте решение только один раз; вернитесь к вопросу, как того требует ситуация.
В большинстве случаев ваше время более ценно, чем компьютер. Если вы думаете, что вам понадобится на полчаса больше, чтобы понять, что делает код позже (скажем, если в нем есть ошибка), и это сэкономило вам всего несколько секунд, то вы в чистом убытке.