종종 개발자는 문제를 해결할 수있는 두 가지 가능한 방법, 즉 관용적이고 읽기 쉬운 방법과 덜 직관적이지만 더 나은 성능을 발휘할 수있는 방법 중에서 선택해야합니다. 예를 들어, C 기반 언어에서는 숫자에 2를 곱하는 두 가지 방법이 있습니다.
int SimpleMultiplyBy2(int x)
{
return x * 2;
}
과
int FastMultiplyBy2(int x)
{
return x << 1;
}
첫 번째 버전은 기술 및 비 기술 독자 모두에게 더 간단하지만 비트 이동이 곱셈보다 더 간단한 작업이기 때문에 두 번째 버전이 더 잘 수행 될 수 있습니다. (지금은 컴파일러의 옵티마이 저가이를 감지하고 최적화하지 않을 것이라고 가정 해 보겠습니다.
개발자로서 초기 시도로 어느 것이 더 좋을까요?
답변
하나 놓쳤습니다.
첫 번째 코드는 정확성을위한 것이고 그 다음은 명확성을위한 것입니다 (물론 둘은 종종 연결되어 있습니다!). 마지막으로 실제로 필요한 실제 경험적 증거가있는 경우에만 최적화를 살펴볼 수 있습니다. 조기 최적화는 정말 악합니다. 최적화에는 거의 항상 시간, 명확성, 유지 보수 비용이 듭니다. 당신은 그것으로 가치있는 것을 구입하고 있는지 확인하는 것이 좋습니다.
좋은 알고리즘은 거의 항상 현지화 된 튜닝보다 우수합니다. 정확하고 명확하며 빠른 코드를 가질 수없는 이유는 없습니다. 하지만 ‘빠름’에 초점을 맞추기 시작하면 불합리하게 운이 좋을 것입니다.
답변
IMO는 성능이 측정되고 더 빠른 버전이 필요할 때까지 분명하게 읽을 수있는 버전입니다.
답변
Don Knuth 에게서 가져옵니다.
조기 최적화는 프로그래밍의 모든 악 (또는 적어도 대부분)의 근원입니다.
답변
가독성 100 %
컴파일러가 “x * 2″=> “x << 1″최적화를 수행 할 수없는 경우 새 컴파일러를 사용하십시오!
또한 프로그램 시간의 99.9 %는 사용자 입력, 데이터베이스 쿼리 및 네트워크 응답을 기다리는 데 소비됩니다. 20 bajillion 시간을 여러 번 수행하지 않는 한 눈에 띄지 않을 것입니다.
답변
주어진 예에서 99.9999 %의 컴파일러는 두 경우 모두 동일한 코드를 생성합니다. 내 일반적인 규칙을 보여줍니다. 먼저 가독성과 유지 관리를 위해 작성하고 필요할 때만 최적화하십시오.
답변
확실히 가독성. 누군가 불평하지 않는 한 속도에 대해 걱정하지 마십시오
답변
가독성.
성능을위한 코딩에는 고유 한 과제가 있습니다. Joseph M. Newcomer가 잘 말했습니다.
최적화는 중요한 경우에만 중요합니다. 그것이 중요 할 때 그것은 매우 중요하지만 그것이 중요하다는 것을 알 때까지 많은 시간을 낭비하지 마십시오. 그것이 중요하다는 것을 알고 있더라도 그것이 중요한 위치를 알아야합니다. 성능 데이터가 없으면 무엇을 최적화해야할지 알 수 없으며 아마도 잘못된 것을 최적화 할 것입니다.
결과는 모호하고 작성하기 어렵고 디버그하기 어렵고 문제를 해결하지 못하는 코드를 유지하기가 어렵습니다. 따라서 (a) 소프트웨어 개발 및 소프트웨어 유지 관리 비용이 증가하고 (b) 성능 효과가 전혀 없다는 두 가지 단점이 있습니다.