Производительность анти паттернов

Question

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

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

* RE-Edit: я вижу маркировку всего как загерметизированного внутреннего (в C #) как преждевременную оптимизацию. *

Мне интересно, какие другие анти-паттерны производительности люди могут знать или встречать?

Answer 1

Самая большая производительность, с которой я столкнулся, это:

• Не измерения производительности до и после изменений.

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

Answer 2

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

Answer 3

Переменное повторное использование.

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

Answer 4

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

Answer 5

Один из тех, с которыми я столкнулся, бросал аппаратное обеспечение в серьезно сломанный код, пытаясь сделать его достаточно быстрым, что-то вроде обращения к статье Джеффа Этвуда, упомянутой в комментарии Руласа. Я не говорю о разнице между ускорением сортировки, которая использует базовый, правильный алгоритм путем запуска его на более быстром оборудовании, по сравнению с использованием оптимизированного алгоритма. Я говорю об использовании не совсем корректного алгоритма домашнего приготовления O (n ^ 3), когда алгоритм O (n log n) находится в стандартной библиотеке. Есть также такие вещи, как процедуры ручного кодирования, потому что программист не знает, что находится в стандартной библиотеке. Это очень расстраивает.

Answer 6

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

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

Answer 7

Использование шаблонов проектирования только для их использования.

Answer 8

Не проводите рефакторинг и не оптимизируйте при написании кода. Крайне важно не пытаться оптимизировать код до его завершения.

Answer 9

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

Answer 10

Джулиан Берч однажды сказал мне:

«Да, но сколько лет работы приложения требуется, чтобы наверстать упущенное разработчиками время?»

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

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

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