함수의 Big O 실행 시간을 변경할 때 무엇이라고 부릅니까?

데이터베이스를 제 O(n^2)시간에 정렬하는 기능이 있다고 가정 해 봅시다 . 리팩토링 O(n log(n))을 수행하여 시간 내에 실행되도록하고 , 그렇게하면 반환 값과 입력을 동일하게 유지하면서 작업이 실행되는 기본 방식을 변경합니다.

이 리팩토링 활동을 무엇이라고합니까?

"속도 향상"은 알고리즘이 실행되는 큰 O 속도를 변경하지 않고 더 빠르게 알고리즘을 만들 수 있기 때문에 옳지 않은 것처럼 보입니다.

"Simplifying"도 옳지 않은 것 같습니다.

이 활동을 무엇이라고합니까?

최신 정보

내가 찾을 수있는 가장 좋은 대답 은 무증상 시간 복잡성을 줄이는 것입니다.

일반적으로 "성능 최적화" 라고 하지만이 용어는 일반적으로 가시적 인 동작을 변경하지 않는 코드의 변경을 의미하므로 "리팩토링"이라고하지 않습니다 . 그리고 Big-O의 변화는 분명히 눈에 띄는 변화라고 부릅니다.

이를 통해 작업이 수행되는 기본 방식을 변경할 것입니다

이 경우 최적화는 해당 기능을 다시 작성 하는 것입니다. "Big-O"가 변경 되더라도 모든 최적화가 반드시 다시 작성되는 것은 아니며, 때로는 그러한 개선을 달성하기 위해 약간의 변경 만 필요하지만, 그럼에도 불구하고 "리팩토링"이라는 용어를 사용하는 것을 꺼려합니다. 변화의 본질에 대해 잘못된 인상을주는 경향이 있습니다.

편집 : 나는 Fowler의 리팩토링 목록을 확인 했으며이 ~ 100이라는 리팩토링 중에서 가장 마지막은 "대체 알고리즘"이라고 합니다. 따라서 이것을 표준 참조로 삼 으면 설명 된 형식의 최적화가 특별한 종류의 리팩토링이라고 할 수있는 작고 회색 영역이 있습니다 (그러나 IMHO는 전형적인 것은 아닙니다). 또한 모든 리팩토링에 대한 Fowler의 목표는 기존 코드를 재 작성하지 않고 유지 관리 및 개발 가능성에 중점을두고 설계를 개선하는 것이지, 성능 최적화가 아니라는 점을 항상 명심하십시오.

나는 표준 용어가 없다고 생각합니다. 일반적으로 사용되는 것이 향상 되었지만 최적화 되거나 속도가 빨라 지면 하드웨어 변경이 아닌 코드 변경에 대해 이야기하고 있음을 명확하게 알 수 있습니다.

다른 사람들이 말했듯이, "최적화"는 알고리즘의 성능을 향상시키는 일반적인 용어입니다. 그러나 최적화는 종종 일정한 요소를 개선하는 것을 의미합니다. 내가 점근 적으로 (시간) 복잡성을 줄 였다고 간결하지만 명확하게 말하고 싶었다면, 나는 "점근 적 성능을 향상시켰다"고 말하고 싶다. 때때로 사람들은 이것을 "스케일링 향상"이라고 설명하지만, 오늘날 특히 모호합니다.

경고 : 점근 적 시간 복잡성을 줄이는 것이 실제 상황 에서 최적화하는 것과 반드시 ​​같을 필요는 없습니다 . 입력 범위에서 프로그램이 실제로는 최적의 성능이 떨어지는 알고리즘에 더 잘 노출되기 때문에 무의식적으로 최적화되지 않은 알고리즘이 종종 사용됩니다.

상황에 따라 다릅니다.

"2 차 런타임 성능 버그 수정"은 일반적으로 내가 보는 것입니다. 그러나 수정이 필요한지 여부 (코드 변경)는 상황에 따라 다릅니다.

데이터베이스는 시간 복잡성을 개선하기위한 많은 도구를 제공합니다. 예를 들어, 데이터베이스에서 상위 N 개의 결과를 얻으려면 그렇게 말하십시오. 비효율적 인 kludge를 내장 된 최적화 된 호출로 변환 할 때 설명이 불필요한 것처럼 보입니다.

코드 검토 (토론)를받을 수있는 이차 런타임 알고리즘을 고려하는 이유는 느리기 때문에 (느리게 상대적입니다. 동료 프로그래머)는 일상 생활에서 기대가 혼합되어 선형 런타임에서 너무 멀리 벗어난 소프트웨어 기능이 본질적으로 불편합니다.

소프트웨어 성능에 대한 많은 고객 불만은 다음 두 가지 범주로 분류됩니다.

• 전체 시스템 (소프트웨어 및 하드웨어)은 예상 사용량을 기준으로 지정되었습니다. 지난 주에 모든 것이 제대로 작동하고 특정 기능에 5 초도 걸리지 않았습니다. 이번 주에는 업데이트를 설치 한 후 동일한 기능이 1 분 이상 걸립니다.

  • 이것은 이전에 벤치마킹 된 성능과 비교 한 것입니다. 고객은 인간의 시간 규모 (초에서 분)의 절대 척도로 미래의 성능을 유지합니다.

• 시스템에 100 개의 작업을 제출했습니다. 단일 작업에 걸리는 시간과 비교하여 처리하는 데 400 배의 시간이 걸리는 이유는 무엇입니까?

  • 고객은 처리 시간이 선형 일 것으로 예상합니다. 실제로 고객은 선형보다 느린 작업이 있다는 것을 이해하거나 받아 들일 수 없습니다.

이러한 이유로 고객은 실행 시간이 모두 버그 인 경우 버그로 간주합니다.

• 선형보다 느리다
• 눈에 띄기

2 차 런타임 알고리즘이 문제를 일으키지 않는다는 것을 설명하는 합법적 인 주장 (즉, 코드 변경이 필요하지 않음) :

• 이 2 차 런타임 함수가 일반적으로 처리하는 작업 크기는 다소 제한적입니다.
• 일반적인 크기 범위를 감안할 때 실제 (절대) 실행 시간은 여전히 ​​무시할 정도로 작습니다.
• 사용자가 실제로 눈에 띄게 충분히 큰 작업을 제출하려고하면 사용자에게 장기 실행 시간에 대한 경고 메시지가 표시됩니다
• 시스템 사용자는 모두 전문가이므로 자신이하는 일을 알고 있습니다. 예를 들어, API 사용자는 API 문서에서 작은 글씨를 읽었어야합니다.

일반적인 응용 프로그램 개발에 유용한 많은 알고리즘은 실제로 선형보다 느리기 때문에 (대부분 정렬에서와 같이 O (N log N)) 실제로 대규모 소프트웨어는 해당 응용 프로그램의 관련 부분 만 정렬하여이 문제를 해결하려고 시도합니다. 유사한 효과를 얻는 히스토그램 (통계) 필터링 기술을 사용하십시오.

이것은 소프트웨어 고객에게 적용되지만 소프트웨어 라이브러리 또는 API 기능의 사용자를 "고객"으로 간주하더라도 대답은 여전히 ​​적용됩니다.

원래 알고리즘이 올바르게 구현 된 경우 (또는 관련이없는 버그 인 경우) "알고리즘 변경" 또는 "알고리즘 대체" 는 이러한 변경으로 인해 정확하게 수행하고 있음을 의미합니다. 이전에 사용 된 알고리즘에 대해 시간 복잡성이 다른 알고리즘을 대체합니다.

이전 시간의 복잡성이 구현의 버그로 인한 것이라면 (예를 들어 실수로 시퀀스에서 내부 루프의 시작점을 재설정하여 O (n)이 O (n ² ) 이되게했다고 말하면 ) "고정 이차 비용 버그 " 또는 유사.

O (n) 시간에 작업을 수행 할 수 있고 O (n ² ) 시간에 오류가 있거나 오류가 발생한 경우 처음부터 코드에 미치는 영향이 동일하다는 점에서 중복이 있습니다. 먼저 의도적 O에 (N을 구현 ² ) 시간 후 여전히 시작 지점을 재설정하지 않고 제대로 작동 것이다 실현하고, 그래서 O (N에 대한 O (n)이 알고리즘 교체 ² ) 하나.

차수 / 배수에 따른 속도 최적화 이것은 수학적으로 부정확 한 언어이지만 순서가 변경되었다는 아이디어를 전달하는 것이 가장 좋습니다.

확장 성 향상 들었습니다.