Защита от паттернов производительности
https://stackoverflow.com/questions/425612
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В настоящее время я работаю на клиента, который окаменевший об изменении паршивого, не поддающегося тестированию и сопровождению кода из-за "соображений производительности".Ясно, что существует множество распространенных заблуждений, а причины не поняты, а просто соблюдаются со слепой верой.
Одним из таких антишаблонов, с которыми я столкнулся, является необходимость пометить как можно больше классов как герметичный внутренний...
* ПОВТОРНОЕредактирование:Я вижу, как все помечается как запечатанный внутренняя (в C #) как преждевременная оптимизация.*
Мне интересно, о каких еще антишаблонах производительности люди могут знать или с которыми сталкиваются?
Решение
Самый производительный антишаблон, с которым я когда-либо сталкивался, - это:
- Не измеряет производительность до и после внесения изменений.
Сбор данных о производительности покажет, был ли определенный метод успешным или нет.Невыполнение этого требования приведет к довольно бесполезным действиям, потому что у кого-то возникает "ощущение" возросшей производительности, когда вообще ничего не изменилось.
Другие советы
Слон в комнате: Сосредоточение внимания на микрооптимизации на уровне реализации, а не на лучших алгоритмах.
Повторное использование переменной.
Я делал это все время, полагая, что я сэкономил несколько циклов на объявлении и уменьшил объем памяти. Эта экономия имела незначительную ценность по сравнению с тем, насколько непослушным он заставлял код отлаживать, особенно если я в итоге переместил блок кода и предположения о начальных значениях изменились.
Преждевременная оптимизация производительности приходит на ум. Я стараюсь избегать оптимизаций производительности любой ценой, и когда я решаю, что они мне нужны, я передаю эту проблему своим коллегам несколько раундов, пытаясь убедиться, что мы поставили оптимизацию в нужное место.
Я столкнулся с тем, что выбрасывал аппаратное обеспечение в серьезно сломанный код, пытаясь сделать его достаточно быстрым, что-то вроде обращения к статье Джеффа Этвуда, упомянутой в комментарии Руласа. Я не говорю о разнице между ускорением сортировки, которая использует базовый, правильный алгоритм путем запуска его на более быстром оборудовании, по сравнению с использованием оптимизированного алгоритма. Я говорю об использовании не совсем корректного алгоритма домашнего приготовления O (n ^ 3), когда алгоритм O (n log n) находится в стандартной библиотеке. Есть также такие вещи, как процедуры ручного кодирования, потому что программист не знает, что находится в стандартной библиотеке. Это очень расстраивает.
Использование шаблонов проектирования только для их использования.
Использование #defines вместо функций, чтобы избежать наказания за вызов функции. Я видел код, в котором расширения определений генерировали огромный и очень медленный код. Конечно, отладку тоже было невозможно. Встроенные функции - это способ сделать это, но их также следует использовать с осторожностью.
Я видел код, в котором независимые тесты были преобразованы в биты в слове, которое можно использовать в операторе switch. Переключение может быть очень быстрым, но когда люди превращают серию независимых тестов в битовую маску и начинают писать около 256 оптимизированных специальных случаев, им лучше иметь очень хороший тест, доказывающий, что это дает прирост производительности. С точки зрения технического обслуживания это действительно боль, и обработка различных тестов независимо делает код намного меньше, что также важно для производительности.
Отсутствие четкой структуры программы - самый большой кодекс из всех. Запутанная логика, которая считается быстрой почти никогда не бывает.
Не проводите рефакторинг и не оптимизируйте при написании кода. Крайне важно не пытаться оптимизировать код до его завершения.
Джулиан Берч однажды сказал мне:
" Да, но сколько лет работы приложения потребуется, чтобы наверстать упущенное разработчиками время? "
Он имел в виду совокупное количество времени, сэкономленное во время каждой транзакции, путем оптимизации, которая потребует определенного количества времени для реализации.
Мудрые слова старого мудреца ... Я часто думаю об этом совете, когда собираюсь заняться оптимизацией в стиле фанк. Вы можете расширить то же понятие немного дальше, учитывая, сколько времени тратится на разработку кода в его нынешнем состоянии и сколько времени экономят пользователи. Вы можете даже взвесить время на основе почасовой ставки разработчика и пользователя, если хотите.
Конечно, иногда это невозможно измерить, например, если приложение электронной коммерции отнимает 1 секунду дольше, вы теряете небольшой процент денег от пользователей, которым скучно в течение этой 1 секунды. Чтобы создать эту одну секунду, вам нужно внедрить и поддерживать оптимизированный код. Оптимизация оказывает положительное влияние на валовую прибыль, а на чистую - отрицательно, поэтому ее гораздо сложнее сбалансировать. Вы можете попробовать - с хорошей статистикой.
Использование вашего языка программирования. Такие вещи, как использование обработки исключений вместо if / else только потому, что в PLSnakish 1.4 это быстрее. Угадай, что? Скорее всего, это не так быстро, и что через два года кто-то, обслуживающий ваш код, очень рассердится на вас из-за того, что вы запутали код и сделали его намного медленнее, потому что в PLSnakish 1.8 сопровождающие исправили проблему, и теперь если / иначе в 10 раз быстрее, чем использование трюков с обработкой исключений. Работайте с вашим языком программирования и фреймворком!
Изменение нескольких переменных одновременно. Это сводит меня с ума помешанные ! Как вы можете определить влияние изменений на систему, если было изменено более одной вещи?
С этим связано внесение изменений, которые не гарантированы наблюдениями. Зачем добавлять более быстрые / дополнительные процессоры, если процесс не связан с процессором?
Общие решения .
То, что данный шаблон / технология работает лучше в одних обстоятельствах, не означает, что в других.
Чрезмерное использование StringBuilder в .Net является частым примером этого.
Однажды мне позвонил бывший клиент и попросил дать мне совет по ускорению их приложений.
Похоже, он ожидал, что я скажу что-то вроде «проверить X, затем проверить Y, затем проверить Z», другими словами, чтобы дать экспертные предположения.
Я ответил, что вам нужно диагностировать проблему. Мои предположения могут ошибаться реже, чем чужие, но они все равно будут ошибаться, и поэтому разочаровывают.
Я не думаю, что он понял.
Некоторые разработчики считают, что быстрое, но неправильное решение иногда предпочтительнее медленного, но правильного. Таким образом, они будут игнорировать различные граничные условия или ситуации, которые "никогда не произойдут". или "не имеет значения" в производстве.
Это никогда не хорошая идея. Решения всегда должны быть «правильными».
Вам может потребоваться изменить определение " правильно " в зависимости от ситуации. Важно, чтобы вы знали / точно определяли, каким должен быть результат для любого условия, и чтобы код давал эти результаты.
Майкл Джексон дает два правила для оптимизации производительности:
<Ол>Если люди беспокоятся о производительности, скажите им, чтобы она стала реальностью - что такое хорошая производительность и как вы тестируете ее? Тогда, если ваш код не соответствует их стандартам, по крайней мере, это то, о чем соглашаются автор кода и пользователь приложения.
Если людей беспокоит нехватка производительности при переписывании окостеневшего кода (например, времени), представьте свои оценки и продемонстрируйте, что это можно сделать в расписании. Предполагая, что это возможно.
Я считаю, что распространенным мифом является то, что сверхлегкий кодекс "близок к металлу" более производительный, чем элегантная модель предметной области.
По-видимому, это было исключено создателем / ведущим разработчиком DirectX, который переписал версию C ++ на C # с огромными улучшениями. [источник требуется]
Присоединение к массиву с помощью (например) push_back () в C ++ STL, ~ = в D и т. д., когда вы знаете, насколько большим должен быть массив, и можете предварительно выделить его.
