종종 개발자는 문제를 해결할 수있는 두 가지 가능한 방법, 즉 관용적이고 읽기 쉬운 방법과 덜 직관적이지만 더 나은 성능을 발휘할 수있는 방법 중에서 선택해야합니다. 예를 들어, 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) 성능 효과가 전혀 없다는 두 가지 단점이 있습니다.
곱셈 대 bitshift는 것입니다 사소한 최적화 그 이익 옆에 아무것도 . 그리고 지적했듯이 컴파일러가이를 수행해야합니다. 그 외에는이 명령이 실행되는 CPU만큼 이득은 무시할 수 있습니다.
반면에 심각한 계산을 수행해야하는 경우 올바른 데이터 구조가 필요합니다. 그러나 문제가 복잡하다면 그 문제를 알아내는 것이 해결책의 일부입니다. 예를 들어, 정렬되지 않은 1000000 개의 객체 배열에서 ID 번호를 검색하는 것을 고려하십시오. 그런 다음 이진 트리 또는 해시 맵을 사용하여 재고하십시오.
그러나 n << C와 같은 최적화는 일반적으로 무시할 수 있고 언제든지 변경하기가 쉽습니다. 코드를 읽기 쉽게 만드는 것은 아닙니다.
항상 최대로 최적화해야하며 성능은 항상 중요합니다. 오늘날 우리가 블로 트웨어를 사용하는 이유는 대부분의 프로그래머가 최적화 작업을 원하지 않기 때문입니다.
그렇긴해도 매끄러운 코딩에 대한 설명이 필요한 곳에 언제든지 주석을 달 수 있습니다.
거의 모든 사람들이 대답에서 말했듯이 가독성을 선호 합니다. 내가 실행하는 100 개 프로젝트 중 99 개는 어려운 응답 시간 요구 사항이 없으므로 쉬운 선택입니다.
코딩을 시작하기 전에 이미 답을 알고 있어야합니다. 일부 프로젝트에는 'Y (밀리) 초 내에 작업 X를 실행할 수 있어야 함'과 같은 특정 성능 요구 사항이 있습니다. 그럴 경우 목표를 달성하고 최적화해야하는 시점을 알고 있습니다. (희망적으로) 이것은 코드를 작성할 때가 아니라 프로젝트의 요구 사항 단계에서 결정됩니다.
좋은 가독성과 나중에 최적화 할 수있는 능력은 적절한 소프트웨어 설계의 결과입니다. 소프트웨어가 사운드 디자인 인 경우 시스템의 다른 부분을 손상시키지 않고 소프트웨어의 일부를 분리하고 필요한 경우 다시 작성할 수 있어야합니다. 게다가 내가 만난 대부분의 진정한 최적화 사례 (실제 저수준 트릭을 무시하고 부수적 임)는 한 알고리즘에서 다른 알고리즘으로 변경하거나 데이터를 디스크 / 네트워크 대신 메모리로 캐싱하는 것입니다.
가독성이 첫 번째 목표입니다.
1970 년대에 육군은 소프트웨어 개발의 "새로운"기술 (하향식 설계, 구조화 된 프로그래밍, 최고 프로그래머 팀 등)을 테스트하여 이들 중 어느 것이 통계적으로 유의미한 차이를 만들 었는지 확인했습니다.
개발에 통계적으로 유의미한 차이를 만든 유일한 기술은 ...
프로그램 코드에 빈 줄 추가.
사전 구조화 된 사전 객체 지향 코드의 가독성 향상은 이러한 연구에서 생산성을 향상시킨 유일한 기술이었습니다.
==============
최적화는 전체 프로젝트가 단위 테스트를 거쳐 계측 준비가 된 경우에만 해결해야합니다. 코드를 최적화해야하는 곳을 알 수 없습니다.
1970 년대 후반의 획기적인 책 Kernigan과 Plauger에서 SOFTWARE TOOLS (1976)와 SOFTWARE TOOLS IN PASCAL (1981)은 하향식 디자인을 사용하여 구조화 된 프로그램을 만드는 방법을 보여주었습니다. 그들은 텍스트 처리 프로그램을 만들었습니다 : 편집기, 검색 도구, 코드 전 처리기.
완성 된 텍스트 형식화 기능이 INSTRUMENTED되었을 때 그들은 대부분의 처리 시간이 텍스트 입력과 출력을 수행하는 세 가지 루틴에서 소비된다는 것을 발견했습니다. (원본에서는 io 함수가 시간의 89 %를 차지했습니다. 파스칼 책에서는 이러한 기능이 55 % 소비!)
이들은이 세 가지 루틴을 최적화 할 수 있었고 합리적이고 관리 가능한 개발 시간과 비용으로 성능을 향상시킬 수있었습니다.
가독성이 없다면 정말로 필요할 때 성능 향상을 얻기가 매우 어려울 것입니다.
성능은 프로그램에 문제가있을 때만 향상되어야합니다.이 구문보다는 병목 현상이 발생할 수있는 곳이 많습니다. <<에서 1ns 개선을 찌르고 있지만 10 분 IO 시간을 무시했다고 가정 해 보겠습니다.
또한 가독성과 관련하여 전문 프로그래머는 컴퓨터 과학 용어를 읽고 이해할 수 있어야합니다. 예를 들어, 우리는 putThisJobInWorkQueue라고 말하지 않고 enqueue 메소드의 이름을 지정할 수 있습니다.
1 시간의 프로세서 시간 비용은 얼마입니까?
프로그래머 시간당 비용은 얼마입니까?
IMHO 두 가지 모두 할 일이 없습니다. 먼저 작동하는 코드를 찾아야합니다. 이것은 성능이나 읽는 능력보다 중요하기 때문입니다. 가독성과 관련하여 : 코드는 어떤 경우에도 항상 읽을 수 있어야합니다.
그러나 코드를 읽을 수없고 동시에 좋은 성능을 제공 할 수없는 이유를 알 수 없습니다. 귀하의 예에서 두 번째 버전은 나에게 첫 번째 버전만큼 읽을 수 있습니다. 그것에 대해 덜 읽기 쉬운 것은 무엇입니까? 프로그래머가 왼쪽으로 이동하는 것이 2의 거듭 제곱을 곱하는 것과 같고 오른쪽으로 이동하는 것이 2의 거듭 제곱으로 나누는 것과 같다는 것을 모르면 일반적인 가독성보다 훨씬 더 기본적인 문제가 있습니다.