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

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

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

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

Некоторые разработчики полагают, что быстрое-но-неправильное решение иногда предпочтительно для медленного-но-корректного. Таким образом, они проигнорируют различные граничные условия или ситуации, которых "никогда не будет происходить", или "не будет иметь значения" в производстве.

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

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

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

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

злоупотребление StringBuilder в .NET является частым примером этого.

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

Michael Jackson дает два правила для оптимизации производительности:

1. не делают этого.
2. (только эксперты) еще не делают этого.

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

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

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

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

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

Тот, с которым я столкнулся, бросал аппаратные средства в серьезно взломанный код, в попытке сделать его достаточно быстро, вид обратной из статьи Jeff Atwood упомянутый в комментарии Rulas. Я не говорю о различии между ускорением вида, который использует основной, корректный алгоритм путем выполнения его на более быстрых аппаратных средствах по сравнению с использованием оптимизированного алгоритма. Я говорю об использовании не, очевидно, корректный, домой варил O (n^3) алгоритм, когда O (n регистрируют n) алгоритм находится в стандартной библиотеке. Существуют также вещи как стандартные программы кодирования руки, потому что программист не знает то, что находится в стандартной библиотеке. То, что очень расстраивающее.

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

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

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

не осуществляют рефакторинг или оптимизируют при написании кода. чрезвычайно важно не попытаться оптимизировать Ваш код перед окончанием его.

Используя шаблоны разработки только, чтобы использовать их.

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

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

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

Юлианская Береза однажды сказала мне:

"Да, но сколько лет запуска приложения на самом деле требуется для восполнения времени, проведенного разработчиками, делающими его?"

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

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

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

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

Он, казалось, ожидал, что я скажу вещи как "проверка X, затем проверю Y, затем проверю Z", другими словами, для обеспечения эксперта предполагает.

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

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