Эффективные шаблоны

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

"Да, но сколько лет работы приложения действительно занимает время, затрачиваемое разработчиками на это?"

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

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

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

Ответ 13

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

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

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

Ответ 14

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

• Не делай этого.
• (только эксперты) Не делайте этого еще.

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

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

Ответ 15

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

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

Ответ 18

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