Як ви називаєте це, коли змінюєте час виконання функції Big O функції [закрито]

Скажімо, у мене є функція, яка сортує базу даних за O(n^2)часом. Я хочу зайнятися рефакторингом, щоб він O(n log(n))працював у часі, і тим самим я зміню принциповий спосіб роботи операції, зберігаючи рівнозначні значення та вхідні дані рівнозначними.

Що я називаю цією рефакторинговою діяльністю?

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

"Спрощення" також не здається правильним.

Як я називаю цю діяльність?

Оновлення

Найкраща відповідь, яку я міг знайти, - це зменшення асимпотичної часової складності.

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

тим самим я зміню принциповий спосіб виконання операції

У цьому випадку ваша оптимізація є переписанням цієї функції. Не кожна оптимізація, навіть якщо вона змінює "Big-O", обов'язково є перезаписом, іноді потрібні лише невеликі зміни для досягнення такого покращення, але навіть тоді я неохоче використовую для цього термін "рефакторинг", оскільки це прагне скласти неправильне враження про характер змін.

EDIT: Я перевірив список рефакторингу Фоулера , і серед цього ~ 100 названих рефакторингах останній називається «Алгоритм заміщення» . Отже, якщо ми сприймаємо це як канонічне посилання, є невелика сіра область, де оптимізацію описаної форми можна назвати особливим видом рефакторингу (але ІМХО не типовим). Зауважимо також, що мета Фаулера з усіма реконструкціями завжди полягала в удосконаленні дизайну з акцентом на ремонтопридатності та еволюціонуванні існуючого коду без його перезапису, і, очевидно, не на оптимізації продуктивності.

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

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

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

Це буде залежати від контексту.

Як правило, "виправлення квадратичної помилки виконання програми". Однак, чи заслуговує це виправлення (зміна коду), залежить від контексту.

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

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

Дуже багато скарг клієнтів на продуктивність програмного забезпечення належать до цих двох категорій:

• Уся система (програмне та апаратне забезпечення) була визначена на основі передбачуваного використання. Минулого тижня все працює нормально, певна функціональність зайняла менше 5 секунд. На цьому тижні після встановлення оновлення ця функція займає більше 1 хвилини.

  • Це порівняння з раніше орієнтованою роботою. Клієнт тримає майбутні показники абсолютної міри людського часового масштабу (від секунд до хвилини).

• Я подав 100 робочих місць у систему. Чому на обробку потрібно 400 разів час порівняно з часом, необхідним для однієї роботи?

  • Замовник очікує, що час обробки буде лінійним. Насправді, замовник не може зрозуміти або прийняти, що існують завдання, які повільніше, ніж лінійні.

З цієї причини замовник вважатиме час виконання помилковим, якщо обидва вірні:

• Повільніше, ніж лінійне
• Помітні (тобто потрапляють у часовий діапазон людини (довше, ніж секунди або хвилини) за типових розмірів завдань)

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

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

Багато алгоритмів, корисних для типової розробки додатків, насправді повільніше, ніж лінійні (в основному O (N log N), як при сортуванні), тому масштабне програмне забезпечення насправді намагатиметься вирішити це, лише сортувавши відповідну частину Дані, або використовувати методи фільтрування гістограми (статистичної), що досягає аналогічного ефекту.

Це стосується клієнтів програмного забезпечення, але якщо ви вважаєте, що користувачі бібліотеки програмного забезпечення або функції API також є "клієнтами", то відповідь все одно застосовуватиметься.

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

Якщо попередній час складність була пов'язана з помилкою в реалізації (наприклад, ви скажете, що ви випадково скинули початкову точку внутрішньої петлі в послідовності, щоб те, що повинно було бути O (n), стало O (n ² )), то "виправлення квадратична помилка витрат " або подібне.

Існує перекриття, оскільки в такому випадку вплив на код однаковий, якщо ви з самого початку знаєте, що робота може бути виконана за O (n) час, і час O (n ² ) був помилкою, або якщо ви спочатку навмисно реалізували його в O (n ² ) час, а потім зрозуміли, що він все одно буде працювати правильно, не скидаючи початкову точку, і таким чином замінили алгоритм O (n) на O (n ² ).

Оптимізація швидкості на порядок / порядки. Хоча це математично неправильна мова, вона найкраще передає думку про зміну Ордену.

Покращили масштабованість. чули також.