Как вы это называете, когда изменяете время выполнения Big O функции [closed]

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

Как я называю эту деятельность по рефакторингу?

«Ускорение - если» - кажется не совсем правильным, поскольку вы можете заставить алгоритм работать быстрее, не изменяя большую скорость O, с которой он выполнялся.

«Упрощение» также не кажется правильным.

Как я называю это занятие?

Обновить

Лучший ответ, который я смог найти, - это уменьшить сложность асимптотического времени.

Обычно это называется «оптимизация производительности» , но я бы не назвал это «рефакторингом», поскольку этот термин обычно относится к изменениям в коде, которые не изменяют его видимое поведение . И изменение в Big-O определенно то, что я бы назвал видимым изменением.

при этом я изменит основной способ работы операции

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

РЕДАКТИРОВАТЬ: Я проверил список рефакторинга Фаулера , и среди этих ~ 100 именованных рефакторингов, самый последний называется "Алгоритм замещения" . Так что, если мы примем это как каноническую ссылку, есть небольшая серая область, где оптимизация описанной формы может быть названа особым видом рефакторинга (но IMHO не типичный). Также обратите внимание, что целью Фаулера при всех рефакторингах всегда было улучшение дизайна с акцентом на ремонтопригодность и эволюционируемость существующего кода без его переписывания и, очевидно, не на оптимизацию производительности.

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

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

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

Это будет зависеть от контекста.

«Исправление квадратичной ошибки производительности во время выполнения» - это обычно то, что я вижу. Однако, заслуживает ли это исправления (изменение кода), зависит от контекста.

Имейте в виду, что базы данных предоставляют множество инструментов для улучшения сложности времени. Например, чтобы получить 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 ² ).

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

Улучшена масштабируемость. слышал также.