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

Question

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

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

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

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

Answer 1

Использование вашего языка программирования. Такие вещи, как использование обработки исключений вместо if / else только потому, что в PLSnakish 1.4 это быстрее. Угадай, что? Скорее всего, это не так быстро, и что через два года кто-то, обслуживающий ваш код, действительно рассердится на вас из-за того, что вы запутали код и заставили его работать намного медленнее, потому что в PLSnakish 1.8 сопровождающие исправили проблему, и теперь если / иначе в 10 раз быстрее, чем использование трюков с обработкой исключений. Работайте с вашим языком программирования и фреймворком!

Answer 2

Изменение более одной переменной одновременно. Это сводит меня с ума помешанных ! Как вы можете определить влияние изменений на систему, если было изменено более одной вещи?

С этим связано внесение изменений, которые не оправдываются наблюдениями. Зачем добавлять более быстрые / дополнительные процессоры, если процесс не связан с процессором?

Answer 3

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

Это никогда не хорошая идея. Решения всегда должны быть «правильными».

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

Answer 4

Общие решения .

То, что данный шаблон / технология работает лучше в одних обстоятельствах, не означает, что в других.

Чрезмерное использование StringBuilder в .Net является частым примером этого.

Answer 5

Как только мне позвонил бывший клиент, он попросил у меня совета по ускорению их приложений.

Он, казалось, ожидал, что я скажу что-то вроде «проверь Х, затем проверь Y, затем проверь Z», другими словами, чтобы дать экспертные догадки.

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

Не думаю, что он понял.

Answer 6

Майкл Джексон дает два правила для оптимизации производительности:

1. Не делай этого.
2. (только для экспертов) Пока не делайте этого.

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

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

Answer 7

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

Это, очевидно, было отменено создателем / ведущим разработчиком DirectX, который переписал версию C ++ на C # с огромными улучшениями. [требуется источник]

Answer 8

Присоединение к массиву с использованием (например) push_back () в C ++ STL, ~ = в D и т. Д., Когда вы знаете, какой размер массива должен быть опережающим, и можете предварительно выделить его.