Яка найсмішніша песимізація, яку ви бачили? [зачинено]

Всі ми знаємо, що передчасна оптимізація є коренем усього зла, оскільки призводить до нечитабельного / нездійсненного коду. Ще гірше - песимізація, коли хтось впроваджує "оптимізацію", тому що думає, що вона буде швидшою, але вона закінчується повільніше, а також буває глючною, нездійсненною і т. Д. Що є найсмішнішим прикладом цього, що ви бачили ?

На старому проекті ми успадкували деяких (інакше чудових) програмістів з вбудованими системами, які мали величезний досвід Z-8000.

Нашим новим середовищем був 32-розрядний Sparc Solaris.

Один з хлопців пішов і поміняв усі інти на шорти, щоб пришвидшити наш код, оскільки захоплення 16 біт оперативної пам’яті було швидше, ніж схоплення 32 біта.

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

Я думаю, що словосполучення "передчасна оптимізація - корінь усього зла" є способом, перевершеним шляхом. Для багатьох проектів це стало приводом не враховувати результати роботи до кінця в проекті.

Ця фраза часто є милицею для людей, щоб уникати роботи. Я бачу, що ця фраза використовується, коли люди дійсно повинні сказати: "Боже, ми насправді не думали про це на передній план і не маємо часу з цим розібратися".

Я бачив набагато більше "смішних" прикладів тупих проблем продуктивності, ніж приклади проблем, введених через "песимізацію"

• Читання одного і того ж ключа реєстру тисячі (або 10 тисяч) разів під час запуску програми.
• Завантаження однієї і тієї ж DLL сотні чи тисячі разів
• Витрата мегабайтів пам'яті, зберігаючи повний шлях до файлів
• Не впорядковуючи структури даних, щоб вони зайняли набагато більше пам'яті, ніж потрібно
• Розміщення всіх рядків, які зберігають імена файлів або шляхи до MAX_PATH
• Безкоштовне опитування за те, що має події, зворотній зв'язок або інші механізми сповіщення

Я вважаю, що кращим є таке твердження: "оптимізація без вимірювання та розуміння зовсім не оптимізація - її просто випадкова зміна".

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

Бази даних - це поле для песимізації.

У вибране:

• Розділіть таблицю на кратні (за діапазоном дат, алфавітним діапазоном тощо), оскільки вона "занадто велика".
• Створіть архівну таблицю для звільнених записів, але продовжуйте об’єднувати її з виробничим столом.
• Дублювання цілих баз даних (відділ / замовник / продукт / тощо)
• Протиставляйте додавання стовпців до індексу, оскільки це робить його занадто великим.
• Створіть безліч підсумкових таблиць, оскільки перерахунок із необроблених даних надто повільний.
• Створіть стовпчики з підполями, щоб заощадити місце.
• Денормалізувати в поля як масив.

Це з моєї голови.

Я думаю, що немає абсолютного правила: деякі речі найкраще оптимізувати наперед, а деякі - ні.

Наприклад, я працював у компанії, де ми отримували пакети даних від супутників. Кожен пакет коштував чималих грошей, тому всі дані були високо оптимізовані (тобто упаковані). Наприклад, широта / довгота не надсилаються як абсолютні величини (поплавці), а як зміщення відносно "північно-західного" кута "поточної" зони. Ми повинні були розпакувати всі дані, перш ніж вони могли бути використані. Але я думаю, що це не песимізація, це розумна оптимізація для зниження витрат на комунікацію.

З іншого боку, наші архітектори програмного забезпечення вирішили, що розпаковані дані повинні бути відформатовані у дуже читабельний XML-документ і зберігатися в нашій базі даних як такий (на відміну від того, щоб кожне поле зберігалося у відповідному стовпчику). Їх ідея полягала в тому, що "XML - це майбутнє", "дисковий простір дешевий" та "процесор дешевий", тому не потрібно було нічого оптимізувати. Результатом було те, що наші 16-байтові пакети були перетворені на 2 КБ документів, що зберігаються в одному стовпчику, і для навіть простих запитів нам довелося завантажувати мегабайти XML-документів у пам'ять! Ми отримували понад 50 пакетів в секунду, тож ви можете собі уявити, наскільки жахливою стала вистава (BTW, компанія збанкрутувала).

Отже, знову немає абсолютного правила. Так, іноді оптимізація занадто рано - це помилка. Але іноді девіз "процесорний / дисковий простір / пам'ять дешевий" - справжній корінь усього зла.

Боже добрий, я думаю, я їх усіх бачив. Найчастіше це намагання виправити проблеми з продуктивністю кимсь, хто надто ледачий, щоб вирішити свій шлях до ПРИЧИНИ цих проблем із роботою або навіть дослідити, чи існує насправді проблема продуктивності. У багатьох з цих випадків мені цікаво, чи це не просто випадок, коли людина хоче спробувати певну технологію і відчайдушно шукає цвях, який підходить під їх новий блискучий молоток.

Ось останній приклад:

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

Я: Чому ти це вважаєш? Яку проблему ви намагаєтеся вирішити?

Йому: Таблиця X занадто широка, ми розділяємо її з міркувань продуктивності.

Я: Що змушує вас вважати це занадто широким?

Він: Консультант сказав, що це занадто багато стовпців, щоб їх було в одній таблиці.

Я: І це впливає на продуктивність?

Він: Так, користувачі повідомили про періодичні уповільнення у модулі XYZ програми.

Я: Як ви знаєте, ширина таблиці є джерелом проблеми?

Йому: Це ключова таблиця, використовувана модулем XYZ, і вона подібна до 200 стовпців. Має бути проблема.

Я (пояснення): Але модуль XYZ, зокрема, використовує більшість стовпців цієї таблиці, а стовпці, які він використовує, непередбачувані, оскільки користувач налаштовує додаток для відображення даних, які вони хочуть відображати з цієї таблиці. Цілком ймовірно, що 95% часу ми з вами все-таки приєднаємось до всіх столів разом, що завдасть шкоди продуктивності.

Він: Консультант сказав, що він занадто широкий, і нам потрібно це змінити.

Я: Хто цей консультант? Я не знав, що ми найняли консультанта, і взагалі не спілкувались із командою розвитку.

Він: Ну, ми їх ще не найняли. Це частина пропозиції, яку вони запропонували, але вони наполягали на тому, що нам потрібно реструктуризувати цю базу даних.

Я: А- а-а. Тож консультант, який продає послуги з перероблення баз даних, вважає, що нам потрібно перепроектувати базу даних ....

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

1. Відсутні індекси в кількох ключових стовпцях.
2. Кілька негідних аналітиків даних, які періодично блокували ключові таблиці (включаючи "занадто широку"), запитуючи виробничу базу даних безпосередньо з MSAccess.

Звичайно, архітектор все ще наполягає на вертикальному розділенні таблиці, що висить на "занадто широкій" мета-проблемі. Він навіть підкріпив свою справу, отримавши пропозицію від іншого консультанта по базі даних, який зміг визначити, чи потрібні серйозні зміни в базі даних, не дивлячись на додаток або не проводячи аналіз ефективності.

Я бачив людей, які використовують альфадрів-7, щоб повністю інкубувати CHX-LT. Це нечаста практика. Більш поширеною практикою є ініціалізація трансформатора ZT, щоб зменшити буферизацію (через більший опір чистого перевантаження) та створити бітеграфічні ознаки стилю java.

Зовсім песимістично!

Нічого не руйнує Земля, я визнаю, але я спіймав людей, які використовують 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 перетворять читабельне об'єднання рядків у оптимізований байт-код для вас, коли це все одно підходить.

Я колись бачив базу даних MSSQL, яка використовувала таблицю "Корінь". Коренева таблиця мала чотири стовпці: GUID (унікальний ідентифікатор), ID (int), LastModDate (дата) та CreateDate (дата). Усі таблиці в базі даних були зовнішнім ключем до таблиці Root. Щоразу, коли в будь-якій таблиці в db створено новий рядок , вам доведеться використовувати пару збережених процедур, щоб вставити запис у таблицю Root, перш ніж ви могли дістатися до фактичної таблиці, про яку ви піклувались (а не в базі даних, яка виконує цю роботу для ви з кількома тригерами прості тригери).

Це створило безлад марних підслуховувань і головних болів, вимагаючи, щоб все, що було написано поверх нього, використовувало проростки (і усувало мої сподівання на впровадження LINQ в компанію. Це було можливо, але просто не варто головного болю), і довершити це не було " t навіть виконати те, що мало робити.

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

О, а схема бази даних виглядала як мутантний павук з пекла.

Як щодо POBI - песимізація очевидно з наміром?

Моїй колезі в 90-х роках набридло бити в дупу генеральним директором тільки тому, що генеральний директор провів перший день кожного випуску програмного забезпечення ERP (на замовлення) з визначенням проблем продуктивності в нових функціональних можливостях. Навіть якщо нові функціональні можливості стискали гігабайти і робили неможливим неможливим, він завжди знаходив якусь деталь, або навіть, здавалося б, головну проблему, на яку завивати. Він вважав, що знає багато про програмування, і його ударили по ногах програміста.

Через некомпетентність критики (він був генеральним директором, а не ІТ-хлопцем), мій колега так і не встиг виправитись. Якщо у вас немає проблеми з продуктивністю, ви не можете її усунути ...

До одного випуску він помістив багато нових затримок (200) функцій (це був Delphi) у новий код. Минуло лише 20 хвилин після виходу наживо, і йому було наказано з’явитися в офіс генерального директора, щоб особисто винести свої прострочені образи.

Єдиною незвичайною річчю мої колеги неміють, коли він повертається, посміхаючись, жартуючи, виходячи на BigMac або два, поки він, як правило, б'є столики, полум’я про генерального директора та компанію, а решту дня проводить до смерті .

Природно, зараз мій колега відпочив на робочому столі один-два дні, вдосконалював свої навички націлювання на Quake - тоді на другий-третій день він видалив затримки дзвінків, відновив і випустив "аварійний патч", про який він поширив слово що він витратив 2 дні і 1 ніч, щоб виправити дірочки.

Це був перший (і єдиний) раз, коли злий генеральний директор сказав "чудову роботу!" йому. Це все, що рахується, правда?

Це було справжнє POBI.

Але це також є свого роду оптимізацією соціальних процесів, тому це на 100% нормально.

Я думаю.

"Незалежність бази даних". Це означало відсутність збережених програм, тригерів тощо - навіть жодних сторонніх ключів.

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

Найкраще використовувати StringBuilder, який я коли-небудь бачив.

Використовуючи регулярний вираз для розділення рядка, коли достатньо простого string.split

Я дуже пізно знаю цю тему, але нещодавно я це бачив:

bool isFinished = GetIsFinished();

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

    case false:
        DoNextStep();
        break;

    default:
        DoNextStep();
}

Знаєте, про всяк випадок, коли булева матиме додаткові значення ...

Найгірший приклад, про який я можу придумати, - це внутрішня база даних в моїй компанії, яка містить інформацію про всіх співробітників. Він отримує щоденне оновлення від HR та має веб-сервіс ASP.NET зверху. Багато інших додатків використовують веб-сервіс для заповнення таких речей, як поля пошуку / спадання.

Песимізм полягає в тому, що розробник думав, що повторні дзвінки до веб-сервісу будуть надто повільними, щоб робити повторні запити SQL. То що він зробив? Подія запуску програми читається у всій базі даних і перетворює все це на об'єкти в пам'яті, що зберігаються на невизначений термін, поки пул додатків не буде перероблений. Цей код був настільки повільним, що знадобиться 15 хвилин, щоб завантажити менше 2000 співробітників. Якщо ви ненавмисно переробили пул додатків протягом дня, це може зайняти 30 хвилин або більше, тому що кожен запит веб-служби запускатиме кілька одночасних перезавантажень. З цієї причини нові робочі місця не з’являться в базі даних у перший день, коли був створений їхній обліковий запис, і тому вони не зможуть отримати доступ до більшості внутрішніх додатків у перші кілька днів, подвівши пальці.

Другий рівень песимізму полягає в тому, що менеджер розробок не хоче доторкатися до нього, боячись зламати залежні додатки, але все ж ми продовжуємо мати періодичні відключення критичних програм на всій компанії через поганий дизайн такого простого компонента.

Здається, ніхто не згадував про сортування, тому я і буду.

Декілька разів я виявив, що хтось виготовив вручну пухирці, тому що ситуація "не вимагала" виклику алгоритму "занадто вигадливого" швидкості, який вже існував. Розробник був задоволений, коли їхні рукодільні бульбашки досить добре працювали над десятьма рядами даних, які вони використовують для тестування. Це не дуже вдало після того, як клієнт додав пару тисяч рядків.

Я колись працював над додатком, який був таким кодом:

 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;

Удвічі ефективність програми.

Мені одного разу довелося спробувати змінити код, який включав ці дорогоцінні камені до класу Константи

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

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

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

Не використовувати функції СУБД з причин "портативності", оскільки "ми можемо захотіти пізніше перейти до іншого постачальника".

Читай мої губи. Для будь-якої домашньої роботи: НЕ БУДЕ ДАЄТЬСЯ!

У мене був колега, який намагався перехитрити оптимізатор нашого компілятора 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% покращення, а іноді й фактично повільнішого коду.

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

Коли я розкопався, я виявив, що оригінальний програміст прагнув прискорити роботу, паралелізуючи аналіз - запустивши нову нитку для кожного додаткового джерела даних. Однак він допустив помилку в тому, що всі потоки вимагали спільного ресурсу, на якому вони зайшли в глухий кут. Звичайно, всі переваги одночасності зникли. Більше того, він розбив більшість систем, щоб запустити 100+ потоків лише для того, щоб усі, крім однієї, були заблоковані. Моя машина "BEfy Dev" стала винятком у тому, що вона спрацьовувала за допомогою набору даних 150 джерел приблизно за 6 годин.

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

Я думаю, я міг запропонувати цей дорогоцінний камінь:

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;
}

Це точно той самий алгоритм, хоч дещо інша реалізація, тому я припускаю, що він відповідає вимогам.

Це може бути на більш високому рівні, ніж те, що ви були після, але виправлення цього (якщо вам це дозволено) також передбачає більший рівень болю:

Наполягаючи на ручному розгортанні диспетчера зв'язків з об’єктами / шару доступу до даних, а не використовувати одну із створених, перевірених, зрілих бібліотек там (навіть після того, як вони вам вказали).

Усі обмеження із зовнішніми ключами були видалені з бази даних, оскільки в іншому випадку буде стільки помилок.

Це не зовсім відповідає питанню, але я все одно згадаю його про застереження. Я працював над розповсюдженим додатком, який працював повільно, і полетів до Колумбія, щоб сидіти на нараді, в першу чергу, спрямованій на вирішення проблеми. Ведуча проекту почала окреслювати реструктуризацію, спрямовану на усунення затримки. Я зголосився, що я провів деякі вимірювання протягом вихідних, які виділили вузьке місце єдиним методом. Виявилося, що в локальному пошуку відсутній запис, через що програма повинна переходити на віддалений сервер під час кожної транзакції. Додавши запис у місцевий магазин, затримку було усунено - проблема вирішена. Зверніть увагу, що реструктуризація не вирішила б проблему.

Перед кожним операцією 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помилки дратують, але це не найкраще рішення для цього.

Як щодо екстремізму ЯГНІ. Це форма передчасної песимізації. Схоже, щоразу, коли ви застосовуєте YAGNI, тоді вам потрібно буде його додати в 10 разів, ніж якщо ви додали його на початку. Якщо ви створили успішну програму, тоді шанси на те, що вам потрібно. Якщо ви звикли створювати програми, життя яких швидко закінчується, тоді продовжуйте практикувати YAGNI, тому що я гадаю, YAGNI.

Не зовсім передчасна оптимізація - але, безумовно, помилково - про це читали на веб-сайті BBC, із статті, що обговорювала Windows 7.

Г-н Курран сказав, що команда Microsoft Windows розглядала всі аспекти операційної системи для вдосконалення. "Нам вдалося поголити 400 мілісекунд часу відключення, трохи обрізаючи музику відключення файлів WAV.

Тепер я ще не пробував Windows 7, тому я можу помилятися, але я готовий зробити ставку на те, що там є інші проблеми, які важливіші за те, скільки часу потрібно на вимкнення. Зрештою, щойно я бачу повідомлення "Вимкнення Windows", монітор вимикається, і я йду геть - як мені ці 400 мілісекунд приносять користь?

Хтось із мого відділу колись написав клас струн. Інтерфейс як CString, але без залежності Windows.

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

Натомість кожен окремий +=виклик примушував перерозподіл, який перетворював повторні додатки в алгоритм Шлемієля Художника О (n²) .

Екс-співробітник шахти (власне мила ) був призначений створити новий модуль для нашої Java ERP, який повинен був збирати та аналізувати дані клієнтів (роздрібна промисловість). Він вирішив розділити КОЖНЕ поле календаря / дату на його компоненти (секунди, хвилини, години, день, місяць, рік, день тижня, біместер, триместр (!)), Оскільки "як інакше я б запитав" кожен понеділок "?"

Нікого не ображаючи, але я просто оцінив завдання (java), яке мало це

import java.lang.*;