Какую самую нелепую пессимизацию вы видели?

Я признаю, что ничего грандиозного, но я поймал людей, использующих StringBuffer для объединения строк вне цикла в Java. Это было что-то простое, вроде поворота

String msg = "Count = " + count + " of " + total + ".";

в

StringBuffer sb = new StringBuffer("Count = ");
sb.append(count);
sb.append(" of ");
sb.append(total);
sb.append(".");
String msg = sb.toString();

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

1. StringBuilder не синхронизирован, поэтому его следует предпочесть StringBuffer в тех случаях, когда ваш код не может быть вызван из нескольких потоков.
2. Современные компиляторы Java превратят читаемую конкатенацию строк в оптимизированный байт-код, когда это в любом случае необходимо.

Я видел людей, использующих alphadrive-7 для полной инкубации CHX-LT. Это необычная практика. Более распространенной практикой является инициализация трансформатора ZT, чтобы уменьшить буферизацию (из-за большей устойчивости к сетевой перегрузке) и создать байтографию в стиле Java.

Совершенно пессимистично!

Базы данных - это игровая площадка для пессимизации.

Избранное включает:

• Разделите таблицу на несколько частей (по диапазону дат, алфавиту и т. д.), Потому что она «слишком велика».
• Создайте архивную таблицу для исключенных записей, но продолжайте ОБЪЕДИНЕНИЕ ее с производственной таблицей.
• Дублируйте целые базы данных по (подразделению / заказчику / продукту / т. Д.)
• Не добавляйте столбцы в индекс, потому что он становится слишком большим.
• Создавайте множество сводных таблиц, потому что пересчет необработанных данных выполняется слишком медленно.
• Создавайте столбцы с подполями для экономии места.
• Денормализовать в поля как массив.

Это не в моей голове.

Это может быть на более высоком уровне, чем то, что вам нужно, но исправление этого (если вам разрешено) также связано с более высоким уровнем боли:

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

Однажды я работал над приложением, полным такого кода:

 1 tuple *FindTuple( DataSet *set, int target ) {
 2     tuple *found = null;
 3     tuple *curr = GetFirstTupleOfSet(set);
 4     while (curr) {
 5         if (curr->id == target)
 6             found = curr;
 7         curr = GetNextTuple(curr);
 8     }
 9     return found;
10 }

Просто удалите found, верните null в конце и измените шестую строку на:

            return curr;

Увеличена производительность приложения вдвое.

Я думаю, что фраза «преждевременная оптимизация - корень всех зол» слишком часто используется. Для многих проектов стало оправданием не принимать во внимание производительность до самого конца проекта.

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

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

• Чтение одного и того же ключа реестра тысячи (или десятки тысяч) раз во время запуска программы.
• Загрузка одной и той же DLL сотни или тысячи раз
• Пустая трата мегабайт памяти из-за ненужного сохранения полных путей к файлам
• Не организовывать структуры данных, чтобы они занимали намного больше памяти, чем им нужно.
• Определение размера всех строк, в которых хранятся имена файлов или пути, до MAX_PATH
• Беспричинный опрос для вещей, у которых есть события, обратные вызовы или другие механизмы уведомления

Я думаю, что лучше всего будет следующее утверждение: «Оптимизация без измерения и понимания - это вообще не оптимизация - это просто случайное изменение».

Работа над хорошей производительностью отнимает много времени - часто больше, чем разработка самой функции или компонента.

Однажды я видел базу данных MSSQL, в которой использовалась «Корневая» таблица. В корневой таблице было четыре столбца: GUID (uniqueidentifier), ID (int), LastModDate (datetime) и CreateDate (datetime). Все таблицы в базе данных имеют внешний ключ к корневой таблице. Всякий раз, когда новая строка создавалась в таблице Любые в базе данных, вам приходилось использовать пару хранимых процедур для вставки записи в корневую таблицу, прежде чем вы могли добраться до фактической таблицы, о которой вы заботились (вместо того, чтобы база данных выполняла работу для вы с несколькими триггерами простые триггеры).

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

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

Да, и диаграмма базы данных выглядела как паук-мутант из ада.

Я думаю, что нет абсолютного правила: некоторые вещи лучше всего оптимизировать заранее, а некоторые нет.

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

С другой стороны, наши разработчики программного обеспечения решили, что распакованные данные должны быть отформатированы в хорошо читаемый XML-документ и сохранены в нашей базе данных как таковые (в отличие от того, чтобы каждое поле сохранялось в соответствующем столбце). Их идея заключалась в том, что «будущее за XML», «дешевое дисковое пространство» и «дешевый процессор», поэтому не было необходимости что-либо оптимизировать. В результате наши 16-байтовые пакеты были преобразованы в документы размером 2 КБ, хранящиеся в одном столбце, и даже для простых запросов нам приходилось загружать в память мегабайты XML-документов! Мы получали более 50 пакетов в секунду, так что вы можете себе представить, насколько ужасной стала производительность (кстати, компания обанкротилась).

Итак, опять же, не существует абсолютного правила. Да, иногда слишком ранняя оптимизация - это ошибка. Но иногда девиз «ЦП / дисковое пространство / память дешево» является настоящим корнем всех зол.

Моему бывшему коллеге (на самом деле s.o.a.b.) было поручено создать новый модуль для нашей Java ERP, который должен был собирать и анализировать данные о клиентах (розничная торговля). Он решил разделить КАЖДОЕ поле календаря / даты и времени на компоненты (секунды, минуты, часы, день, месяц, год, день недели, биметр, триместр (!)), Потому что «как еще я мог бы запросить« каждый понедельник »?»

Ни в коем случае не обижайтесь, но я только что оценил задание (java), в котором было это

import java.lang.*;

Использование регулярного выражения для разделения строки, когда достаточно простого string.split

Господи, думаю, я их всех видел. Чаще всего это попытка исправить проблемы с производительностью кем-то, кто слишком ленив, чтобы найти их ПРИЧИНУ этих проблем с производительностью или даже выяснить, действительно ли существует проблема с производительностью. Во многих из этих случаев я задаюсь вопросом, не является ли это просто случаем, когда человек хочет опробовать определенную технологию и отчаянно ищет гвоздь, который подошел бы их новому блестящему молотку.

Вот недавний пример:

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

Мне: Почему вы об этом думаете? Какую проблему вы пытаетесь решить?

Ему: Таблица X слишком велика, мы разбиваем ее по соображениям производительности.

Мне: С чего вы взяли, что он слишком широкий?

Ему: Консультант сказал, что слишком много столбцов для одной таблицы.

Мне: А это влияет на производительность?

Ему: Да, пользователи сообщали о периодических замедлениях работы модуля XYZ приложения.

Мне: Как узнать, что ширина таблицы является источником проблемы?

Ему: Это таблица ключей, используемая модулем XYZ, и она похожа на 200 столбцов. Это должно быть проблема.

Я (объясняя): Но модуль XYZ, в частности, использует большинство столбцов в этой таблице, а используемые им столбцы непредсказуемы, поскольку пользователь настраивает приложение для отображения данных, которые он хочет отобразить из этой таблицы. Вероятно, что в 95% случаев мы все равно объединим все таблицы вместе, что снизит производительность повредить.

Ему: Консультант сказал, что он слишком широк и нам нужно его изменить.

Мне: Кто этот консультант? Я не знал, что мы наняли консультанта, и они вообще не разговаривали с командой разработчиков.

Ему: Ну, мы их еще не наняли. Это часть предложения, которое они предложили, но они настаивали на том, что нам нужно изменить архитектуру этой базы данных.

Мне: Угу. Итак, консультант, который продает услуги по изменению дизайна базы данных, думает, что нам нужен редизайн базы данных ....

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

1. Отсутствуют индексы по нескольким ключам столбцы.
2. Несколько аналитиков-мошенников, которые периодически блокировка ключевых таблиц (в том числе "слишком широкий") запросив производственная база данных напрямую с MSAccess.

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

Проверка перед КАЖДОЙ операцией javascript, существует ли объект, с которым вы работаете.

if (myObj) { //or its evil cousin, if (myObj != null) {
    label.text = myObj.value; 
    // we know label exists because it has already been 
    // checked in a big if block somewhere at the top
}

Моя проблема с этим типом кода в том, что никого не волнует, а что, если его не существует? Просто ничего не делать? Не оставляете отзыв пользователю?

Я согласен, что ошибки Object expected меня раздражают, но это не лучшее решение для этого.

Худший пример, который я могу придумать, - это внутренняя база данных в моей компании, содержащая информацию обо всех сотрудниках. Он получает еженощные обновления от отдела кадров и имеет поверху веб-службу ASP.NET. Многие другие приложения используют веб-службу для заполнения таких вещей, как поля поиска / раскрывающегося списка.

Пессимизм заключается в том, что разработчик думал, что повторные вызовы веб-службы будут слишком медленными, чтобы делать повторяющиеся запросы SQL. И что он сделал? Событие запуска приложения считывает всю базу данных и преобразует все это в объекты в памяти, которые хранятся на неопределенный срок, пока пул приложений не будет перезапущен. Этот код был настолько медленным, что на его загрузку ушло менее 2000 сотрудников. Если вы непреднамеренно перезапустили пул приложений в течение дня, это может занять 30 минут или больше, потому что каждый запрос веб-службы будет запускать несколько одновременных перезагрузок. По этой причине новые сотрудники не будут отображаться в базе данных в первый день создания их учетной записи и, следовательно, не смогут получить доступ к большинству внутренних приложений в первые несколько дней своей работы.

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

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

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

public static String COMMA_DELIMINATOR = ",";
public static String COMMA_SPACE_DELIMINATOR = ", ";
public static String COLIN_DELIMINATOR = ":";

Каждый из них многократно использовался в остальной части приложения для разных целей. COMMA_DELIMINATOR засорял код более чем 200 использованием в 8 различных пакетах.

Я собирался упомянуть StringBuilder для крошечных / нециклических строковых конкатенаций, но он был упомянут.

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

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

«Эта часть не должна быть быстрой» (архивирование журналов) «Эта часть должна быть очень быстрой» (принятие новых подключений)

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

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

Похоже, никто не упомянул о сортировке, так что я скажу.

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

Как насчет экстремизма ЯГНИ. Это форма преждевременной пессимизации. Кажется, что всякий раз, когда вы применяете YAGNI, он вам в конечном итоге нужен, что приводит к 10-кратным усилиям, чтобы добавить его, чем если бы вы добавляли его в начале. Если вы создадите успешную программу, скорее всего, она вам понадобится. Если вы привыкли создавать программы, жизнь которых быстро заканчивается, продолжайте практиковать ЯГНИ, потому что тогда, я полагаю, ЯГНИ.

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

Аааа, но побитовое сравнение быстрее, чем равенство, и дааай быстрее, чем соединение, верно?

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

P.s.

Я знаю, о чем вы думаете, это должна была быть двоичная строка, верно? :)

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

Некоторые мои коллеги, которые участвовали в проекте «оптимизации» существующих пакетов на стороне сервера (написанных на C++), «оптимизировали» до смерти класс ведения журнала (!), Используя специфичный для Win32 код и функции.

Возможно, узкое место было в logger.write (...), кто знает ...

Один сотрудник должен был проверить доступ к странице для определенной роли - только «Администратор». Вот что она написала:

.

if ( CurrentUser.CurrentRole == "Role1" || CurrentUser.CurrentRole == "Role2")  
{
// Access denied
} 
else
{
// Access granted
}

вместо

if ( !CurrentUser.CurrentRole.equals("Admin") ) 
{
 // access denied
}  

Таким образом, всякий раз, когда в систему добавлялась новая роль, она имела доступ ко всем конфиденциальным страницам.

Тот же сотрудник был также объединен для создания и архивной таблицы для всех запросов.

Полагаю, я мог бы предложить эту жемчужину:

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    // Find out how many bytes our value uses
    // so we don't do any uneeded work.
    if (value & 0xffff0000)
    {
        if ((value & 0xff000000) == 0)
            tmp = 3;
        else
            tmp = 4;
    }
    else if (value & 0x0000ff00)
        tmp = 2;

    switch (tmp)
    {
        case 4:
            ISQRT_INNER(15);
            ISQRT_INNER(14);
            ISQRT_INNER(13);
            ISQRT_INNER(12);
        case 3:
            ISQRT_INNER(11);
            ISQRT_INNER(10);
            ISQRT_INNER( 9);
            ISQRT_INNER( 8);
        case 2:
            ISQRT_INNER( 7);
            ISQRT_INNER( 6);
            ISQRT_INNER( 5);
            ISQRT_INNER( 4);
        case 1:
            ISQRT_INNER( 3);
            ISQRT_INNER( 2);
            ISQRT_INNER( 1);
            ISQRT_INNER( 0);
    }
#undef ISQRT_INNER
    return root;
}

Поскольку квадратный корень вычислялся в очень чувствительном месте, я получил задание найти способ сделать это быстрее. Этот небольшой рефакторинг сократил время выполнения на треть (для комбинации используемого оборудования и компилятора, YMMV):

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1, root = 0;
    #define ISQRT_INNER(shift) \
    { \
        if (value >= (tmp = ((root << 1) + (1 << (shift))) << (shift))) \
        { \
            root += 1 << shift; \
            value -= tmp; \
        } \
    }

    ISQRT_INNER (15);
    ISQRT_INNER (14);
    ISQRT_INNER (13);
    ISQRT_INNER (12);
    ISQRT_INNER (11);
    ISQRT_INNER (10);
    ISQRT_INNER ( 9);
    ISQRT_INNER ( 8);
    ISQRT_INNER ( 7);
    ISQRT_INNER ( 6);
    ISQRT_INNER ( 5);
    ISQRT_INNER ( 4);
    ISQRT_INNER ( 3);
    ISQRT_INNER ( 2);
    ISQRT_INNER ( 1);
    ISQRT_INNER ( 0);

#undef ISQRT_INNER
    return root;
}

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

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

unsigned long isqrt(unsigned long value)
{
    unsigned long tmp = 1 << 30, root = 0;

    while (tmp != 0)
    {
        if (value >= root + tmp) {
            value -= root + tmp;
            root += tmp << 1;
        }
        root >>= 1;
        tmp >>= 2;
    }

    return root;
}

Это точно такой же алгоритм, хотя и немного другая реализация, поэтому я полагаю, что он подходит.

Еще один модный трюк с производительностью :)

if (!loadFromDb().isEmpty) {
    resultList = loadFromDb();
    // do something with results
}

За небольшую цену дополнительного попадания в базу данных вы сэкономите все это время, выполняя примерно 10 строк кода, которые, вероятно, в любом случае мало что сделают для пустого списка. И такие вещи были разбросаны по всему коду :)

У меня был коллега, который пытался перехитрить оптимизатор нашего компилятора C, и программа переписала код, который мог прочитать только он. Одним из его любимых приемов было изменение читаемого метода, например (создание кода):

int some_method(int input1, int input2) {
    int x;
    if (input1 == -1) {
        return 0;
    }
    if (input1 == input2) {
        return input1;
    }
    ... a long expression here ...
    return x;
}

в это:

int some_method() {
    return (input == -1) ? 0 : (input1 == input2) ? input 1 :
           ... a long expression ...
           ... a long expression ...
           ... a long expression ...
}

То есть первая строка однократно читаемого метода станет «return», а вся остальная логика будет заменена глубоко вложенными терниарными выражениями. Когда вы пытались спорить о том, почему это невозможно поддерживать, он указывал на тот факт, что результат сборки его метода был на три или четыре инструкции короче. Это не обязательно было Быстрее, но всегда было на бит крошечный короче. Это была встроенная система, в которой использование памяти иногда имело значение, но были гораздо более простые оптимизации, которые можно было бы сделать, чем то, что оставило бы код читаемым.

Затем, после этого, по какой-то причине он решил, что ptr->structElement слишком нечитабелен, поэтому он начал заменять все это на (*ptr).structElement, исходя из теории, что он более читабелен и быстрее.

Превращение читаемого кода в нечитаемый - максимум на 1%, а иногда и более медленный код.

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

В рамках одного старого проекта мы унаследовали некоторых (в остальном превосходных) программистов встроенных систем, которые имели большой опыт работы с Z-8000.

Нашей новой средой был 32-битный Sparc Solaris.

Один из ребят пошел и поменял все целые на короткие, чтобы ускорить наш код, так как захват 16 бит из ОЗУ был быстрее, чем захват 32 бита.

Мне пришлось написать демонстрационную программу, чтобы показать, что захват 32-битных значений в 32-битной системе был быстрее, чем захват 16-битных значений, и объяснить, что для захвата 16-битного значения ЦП должен был сделать 32-битное значение шириной. доступ к памяти, а затем замаскировать или сдвинуть биты, которые не нужны для 16-битного значения.

Многие программисты не знают или не хотят знать SQL, поэтому они находят «уловки», чтобы избежать реального использования SQL, чтобы они могли получить данные в массиве. Массивы делают некоторых людей счастливыми. (Мне нравятся и курсоры, и массивы. Coke и Pepsi.) Я нашел эти два блока кода в коде некоторых объектно-ориентированных программистов, которые жаловались на медленную работу реляционных баз данных. (ответ - не больше памяти или больше процессоров.)

Таблица в этом случае представляет собой огромную таблицу с uniqueid_col - уникальным идентификатором или уникальной строкой.

Загрузите эти данные в arrayX (потому что массивы должны быть быстрее)

   Select uniqueid_col, col2, col3
     from super_big_tbl
 

(псевдокод)

Loop 
   arrayX.next_record
    if uniqueid_col = '829-39-3984'
      return col2
    end if
end loop
 

(Мой ответ внизу.)

Следующая простая ошибка, которую я тоже видел. Идея в том, что таким образом вы никогда не получите дубликат:

   Select uniqueid_col, col2, col3
     from super_big_tbl
 group by uniqueid_col, col2, col3
   having uniqueid_col = '829-39-3984'

Правильный синтаксис должен быть

   Select uniqueid_col, col2, col3
     from super_big_tbl
    where uniqueid_col = '829-39-3984'
   

Я знаю, что очень поздно к этой теме, но недавно увидел это:

bool isFinished = GetIsFinished();

switch (isFinished)
{
    case true:
        DoFinish();
        break;

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Знаете, на случай, если у логического есть какие-то дополнительные значения ...

Не совсем преждевременная оптимизация - но определенно ошибочная - это было прочитано на веб-сайте BBC из статьи, посвященной Windows 7.

Mr Curran said that the Microsoft Windows team had been poring over every aspect of the operating system to make improvements. "We were able to shave 400 milliseconds off the shutdown time by slightly trimming the WAV file shutdown music.

Я еще не пробовал Windows 7, поэтому могу ошибаться, но готов поспорить, что есть и другие проблемы, которые более важны, чем время, необходимое для завершения работы. В конце концов, как только я вижу сообщение «Завершение работы Windows», монитор выключается, и я ухожу - какую пользу мне принесут эти 400 миллисекунд?

Большой номер один на все времена, с которым я снова и снова сталкиваюсь в собственном программном обеспечении:

Не использовать возможности СУБД по причинам «переносимости», потому что «мы можем захотеть перейти к другому поставщику позже».

Читай по губам. Для любых внутренних работ: ЭТО НЕ БУДЕТ!

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

• Коллекции карт или "словари"
  Обычно в них используется какое-то хеш-кодирование, поэтому они будут иметь производительность O (1), но не будут работать даже при заполнении гораздо большим количеством элементов, чем обычно используется.

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

• Уведомления и обработка событий как способ сохранения согласованности данных Поскольку структура данных редко нормализуется, необходимо управлять несогласованностью, и уведомление является обычным методом, поскольку он якобы решает проблему «немедленно». Однако есть большая разница между оперативностью и эффективностью. Также «свойства», когда они Get или Set, поощряются к проникновению глубоко в структуру данных, чтобы попытаться сохранить ее согласованность. Эти методы «короткого поводка» могут привести к большим потерям вычислений. Методы «длинного поводка», такие как периодическое циклическое прохождение структуры данных для «восстановления», могут быть немного менее «немедленными», но гораздо более эффективными.

Примеры

У меня есть намеренная ... Однажды я реализовал сортировку с возвратом ... просто как доказательство концепции;)) Само собой разумеется, ее производительность была ужасной.

var stringBuilder = new StringBuilder();
stringBuilder.Append(myObj.a + myObj.b + myObj.c + myObj.d);
string cat = stringBuilder.ToString();

Лучшее использование StringBuilder, которое я когда-либо видел.

Как насчет ПОБИ - пессимизация явно умышленно?

Мой коллега в 90-х устал от того, что генеральный директор пинал ему задницу только потому, что генеральный директор проводил первый день каждого выпуска программного обеспечения ERP (нестандартного), выявляя проблемы производительности в новых функциях. Даже если новые функциональные возможности сокрушили гигабайты и сделали невозможное возможным, он всегда находил какие-то детали или даже, казалось бы, серьезную проблему, над которой можно было ныть. Он считал, что хорошо разбирается в программировании, и получил свое удовольствие, надрывая задницы программистам.

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

Пока в одном выпуске он не поместил много вызовов функций Delay (200) (это был Delphi) в новый код. Прошло всего 20 минут после запуска, и ему было приказано явиться в офис генерального директора, чтобы лично принести свои запоздалые оскорбления.

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

Естественно, теперь мой коллега отдыхал один или два дня за своим столом, улучшая свои навыки прицеливания в Quake - затем на второй или третий день он удалил вызовы задержки, восстановил и выпустил «аварийный патч», о котором он распространил слух. что он потратил 2 дня и 1 ночь, чтобы исправить дыры в производительности.

Это был первый (и единственный) раз, когда злой генеральный директор сказал «отличная работа!» ему. Это все, что имеет значение, верно?

Это был настоящий ПОБИ.

Но это также своего рода оптимизация социальных процессов, так что это на 100% нормально.

Я думаю.

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

По мере того, как я копался, я обнаружил, что исходный программист стремился ускорить процесс за счет распараллеливания анализа - запуска нового потока для каждого дополнительного источника данных. Однако он допустил ошибку в том, что все потоки требовали общего ресурса, на котором они зашли в тупик. Конечно, все преимущества параллелизма исчезли. Более того, из-за сбоя большинства систем запускались более 100 потоков только для того, чтобы заблокировать все, кроме одного. Моя мощная машина разработчика была исключением, поскольку она обработала набор данных из 150 источников примерно за 6 часов.

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

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

Кто-то в моем отделе однажды написал струнный класс. Интерфейс похож на CString, но без зависимости от Windows.

Одна из «оптимизаций», которую они сделали, заключалась в том, чтобы нет выделял больше памяти, чем необходимо. По-видимому, не понимая, что такие классы, как std::string, выделяют избыточную память, заключаются в том, что последовательность операций += может выполняться за O (n) раз.

Вместо этого каждый звонок += принудительно перераспределяет, что превращает повторяющиеся добавления в O (n²) Алгоритм Шлемиля Художника.

Одна компания, которую я посетил в качестве консультанта много лет назад, написала функцию сортировки, которая выглядела примерно так:

procedure sort(string[] values, string direction)
begin
  while not sorted do
  begin
    for every value in values
    begin
      if direction = "Ascending" then
      begin
        ... swap values in ascending order
      end
      else if direction = "Descending" then
      begin
        ... swap values in descending order
      end
    end;
  end;
end;

Это алгоритм пузырьковой сортировки (который сам по себе неэффективен) с сравнение строк для направления во внутреннем цикле! Я с трудом поверил своим глазам и объяснил, что да, я, вероятно, могу сделать здесь пару улучшений скорости (в конце концов, они были моими клиентами, поэтому мне пришлось дипломатично заявить, что это был самый неоптимальный код, который я когда-либо видел :-))

while true; do echo 3 > /proc/sys/vm/drop_caches; sleep 3600; done

Это заставляло ядро ​​тратить время на очистку дискового кеша, и как только это удалось, все работало медленно, пока кеш не был заполнен заново. Вызвано неправильным представлением о том, что кеш-память диска препятствует доступу памяти для использования приложениями.