왜 많은 개발자들이 성능, 가독성 및 유지 관리 성이 공존 할 수 없다고 생각합니까?

이 질문에 답 하면서 , 왜 많은 개발자들이 좋은 디자인이 성능을 설명하지 않아야한다고 생각하는지 궁금해지기 시작했습니다. 그렇게하면 가독성 및 / 또는 유지 관리에 영향을 줄 수 있기 때문입니다.

좋은 디자인은 디자인 할 때 성능도 고려한다고 생각하며, 좋은 디자인을 가진 좋은 개발자는 가독성이나 유지 관리에 부정적인 영향을 미치지 않으면 서 효율적인 프로그램을 작성할 수 있다고 생각합니다.

극단적 인 경우가 있음을 인정하지만, 많은 개발자가 효율적인 프로그램 / 디자인이 가독성 및 / 또는 유지 관리 성이 좋지 않아 성능이 디자인 고려 사항이 아니라고 주장하는 이유는 무엇입니까?

나는 그러한 견해는 일반적으로 조기 (미세) 최적화 시도에 대한 반응 이라고 생각한다 . 이는 여전히 널리 퍼져 있으며 보통 선보다 더 해롭다. 그러한 견해에 맞서려고 할 때, 다른 극단에 빠지거나 최소한 닮아보기 쉽습니다.

그럼에도 불구하고 최근 수십 년 동안 엄청난 양의 하드웨어 리소스가 개발되면서 오늘날 작성된 대부분의 프로그램에서 성능이 주요 제한 요소가되지 않았다는 것은 사실입니다. 물론 성능이 주요 문제가 될 수있는 경우 를 식별 하기 위해 설계 단계에서 예상되고 달성 가능한 성능을 고려해야합니다 . 그리고 처음부터 성능을 위해 디자인하는 것이 중요합니다. 그러나 전반적인 단순성, 가독성 및 유지 관리 성이 여전히 더 중요 합니다. 다른 사람들이 지적했듯이 성능 최적화 코드는 가장 간단한 작업 솔루션보다 더 복잡하고 읽기 및 유지 관리가 어렵고 버그가 발생하기 쉽습니다. 따라서 최적화에 소요 어떤 노력을해야 입증 - 그냥 믿어-프로그램의 장기적인 유지 보수성을 가능한 한 저하시키지 않으면 서 실질적인 이점을 제공합니다. 따라서 우수한 설계는 복잡하고 성능 집약적 인 부품을 나머지 코드 와 분리하여 가능한 한 단순하고 깨끗하게 유지합니다.

고성능 코드를 개발하는 개발자의 입장에서 질문에 따라 디자인에서 고려해야 할 사항이 몇 가지 있습니다.

• 너무 비관하지 마십시오. 복잡성이 동일한 두 가지 디자인 중에서 선택할 수있는 경우 최고의 성능 특성을 가진 디자인을 선택하십시오. 유명한 C ++ 예제 중 하나는 루프에서 카운터 (또는 반복자)의 증가 후 확산의 유병률입니다. 이것은 전혀 불필요한 조기 비관 화로 비용이 들지 않을 수도 있지만 그렇게하지 마십시오.
• 대부분의 경우 아직 미세 최적화 근처에 갈 사업이 없습니다. 알고리즘 최적화는 성능 저하가 적으며 실제로는 저수준 최적화보다 이해하기가 훨씬 쉽습니다.
• 성능이 절대적으로 중요한 경우에만 작동이 중단됩니다. 실제로 코드를 가능한 한 많이 격리하면 더러워지고 더러워집니다. 캐싱 구성표, 게으른 평가, 캐싱을위한 메모리 레이아웃 최적화, 인라인 내장 또는 어셈블리 블록, 템플릿 레이어 레이어 등으로 인해 실제로 더러워집니다. 여기서 미친 것처럼 테스트하고 문서화합니다. 이 코드에서 유지 관리를 수행해야 할 경우 상처를 입을 수 있지만 성능이 절대적으로 중요하기 때문에해야합니다. 편집 : 그건 그렇고,이 코드가 아름답 지 않다고 말할 수는 없으며 가능한 한 아름답게 만들어야하지만 여전히 최적화되지 않은 코드와 비교할 때 매우 복잡하고 복잡합니다.

바로 잡으십시오, 아름답게, 빨리 잡으십시오. 그와 같은 순서로.

@greengit의 멋진 다이어그램을 "빌리기"를 가정하고 약간의 추가를한다면 :

|
P
E
R
F
O  *               X <- a program as first written
R   * 
M    *
A      *
N        *
C          *  *   *  *  *
E
|
O -- R E A D A B I L I T Y --

우리는 모두 트레이드 오프 곡선이 있다는 것을 "학습"했습니다. 또한, 우리는 모두 우리가 어떤 주어진 프로그램 우리의 쓰기가 너무 꽉가되도록 최적의 프로그래머 가정 한 곡선에 . 프로그램이 곡선에있는 경우 한 차원을 개선하면 다른 차원에서도 비용이 발생합니다.

내 경험상 프로그램은 조정, 조정, 망치질, 왁스 처리 및 일반적으로 "코드 골프"로 전환되어 모든 곡선에 가깝습니다. 대부분의 프로그램은 모든 차원에서 개선의 여지가 충분합니다. 여기 내가 의미하는 바가 있습니다.

정확하게는 고성능 소프트웨어 구성 요소가 다른 소프트웨어 구성 요소 (일반적으로 다른 모든 것)보다 훨씬 복잡하기 때문입니다.

그렇더라도 성능 지표가 매우 중요한 요구 사항 인 경우 설계가 그러한 요구 사항을 수용하기 위해 복잡성을 갖는 것이 중요합니다. 위험은 구성 요소에서 몇 밀리 초를 짜려고하는 비교적 간단한 기능으로 스프린트를 낭비하는 개발자입니다.

그럼에도 불구하고 디자인의 복잡성은 개발자가 이러한 디자인을 빠르게 배우고 익히는 능력과 직접적인 상관 관계가 있으며 복잡한 구성 요소의 기능을 추가로 수정하면 단위 테스트에서 잡을 수없는 버그가 발생할 수 있습니다. 복잡한 설계에는 더 많은 측면과 가능한 테스트 사례가있어 100 % 단위 테스트 범위를 목표로 삼을 수 있습니다.

그렇게 말하면 성능이 떨어지는 소프트웨어 구성 요소는 원래 작성자의 무지에 따라 어리석게 작성되고 불필요하게 복잡하기 때문에 성능이 떨어질 수 있습니다 (단지 하나의 작업을 수행 할 때 단일 엔티티를 작성하기 위해 8 개의 데이터베이스 호출을 수행함) , 완전히 불필요한 코드로 인해 단일 코드 경로를 초래하는 등 ...) 이러한 경우는 리팩토링의 결과로 발생하는 코드 품질 및 성능 향상의 문제이며, 의도 한 결과가 아닙니다.

그러나 잘 설계된 구성 요소를 가정하면 성능을 위해 조정 된 유사하게 설계된 구성 요소 (다른 모든 요소는 동일)보다 항상 덜 복잡합니다.

그런 것들이 공존 할 수있는 것은 아닙니다. 문제는 첫 번째 반복에서 모든 사람의 코드가 느리고 읽을 수 없으며 유지할 수 없다는 것입니다. 나머지 시간은 가장 중요한 것을 개선하는 데 소비됩니다. 그것이 성능이라면 그것을 찾으십시오. 끔찍하게 끔찍한 코드를 작성하지 말고 X가 빠르면 X를 빨리 만드십시오. 나는 성능과 청결이 기본적으로 상관이 없다고 생각합니다. 수행자 코드는 못생긴 코드를 유발하지 않습니다. 그러나 모든 코드를 빠르게 조정하는 데 시간을 소비한다면 시간을 보내지 않은 것을 추측하십시오. 코드를 깨끗하고 유지 보수 가능하게 만듭니다.

    |
    피
    이자형
    아르 자형
    에프
    O *
    R * 
    M *
    A *
    N *
    C * * * * *
    이자형
    |
    O-가독성

보다시피 ...

• 가독성을 희생하면 성능을 향상시킬 수 있지만 그 정도만 증가합니다. 특정 시점이 지나면 더 나은 알고리즘과 하드웨어와 같은 "실제"수단을 사용해야합니다.
• 또한 가독성을 희생하여 성능을 잃을 수 있습니다. 그런 다음 성능에 영향을 미치지 않으면 서 원하는만큼 프로그램을 읽을 수있게 만들 수 있습니다. 예를 들어 더 유용한 의견을 추가해도 실적에는 영향을 미치지 않습니다.

따라서 성능과 가독성은 거의 관련이 없으며 대부분의 경우 전자를 선호하는 인센티브는 없습니다. 저는 여기서 고급 언어에 대해 이야기하고 있습니다.

제 생각에는 성능이 실제 문제 (예 : 요구 사항) 인 경우 고려해야합니다 . 그렇게하지 않으면 마이크로 최적화가 발생하는 경향이 있으며, 여기저기서 몇 마이크로 초를 절약하기 위해 코드가 난독 화되어 코드 유지 관리 및 읽기가 쉽지 않습니다. 대신 필요한 경우 시스템의 실제 병목 현상에 중점을두고 성능을 강조해야합니다.

요점은 하지 가독성을 항상 우선해야 효율. 알고리즘이 매우 효율적이어야한다는 것을 알면 알고리즘을 개발하는 데 사용하는 요소 중 하나가됩니다.

문제는 대부분의 유스 케이스가 빠른 코드를 가리지 않아도된다는 것입니다. 대부분의 경우 IO 또는 사용자 상호 작용으로 인해 알고리즘 실행보다 훨씬 더 많은 지연이 발생합니다. 요점은 병목이 무엇인지 모르는 경우 좀 더 효율적으로 만들기 위해 벗어나지 말아야한다는 것입니다.

성능을 위해 코드를 최적화하면 일반적으로 가장 직관적이 아닌 영리한 방식으로 작업을 수행하기 때문에 더 복잡해집니다. 더 복잡한 코드는 유지 관리가 어렵고 다른 개발자가 선택하기가 더 어렵습니다 (둘 다 고려해야하는 비용). 동시에 컴파일러는 일반적인 경우를 최적화하는 데 매우 능숙합니다. 일반적인 경우를 개선하려는 시도는 컴파일러가 더 이상 패턴을 인식하지 못하므로 코드를 빠르게 만드는 데 도움이되지 않을 수 있습니다. 이것이 성능에 대한 걱정없이 원하는 것을 쓰라는 의미는 아닙니다. 비효율적 인 일을해서는 안됩니다.

포인트는 작은 것들에 대해 걱정하지하는 것입니다 수있는 더 나은 일을합니다. 프로파일 러를 사용하여 1) 현재 가지고있는 것이 문제이고 2) 프로파일을 변경 한 것이 개선 된 것을 확인하십시오.

대부분의 프로그래머는 대부분의 경우 성능 코드가 응용 프로그램의 다른 코드보다 훨씬 많은 정보 (컨텍스트, 하드웨어 지식, 글로벌 아키텍처에 대한 코드)를 기반으로하는 코드이기 때문에 직감을 느끼는 것 같습니다. 대부분의 코드는 함수와 같은 모듈 방식으로 일부 추상화로 캡슐화되는 특정 문제에 대한 일부 솔루션 만 표현하며 컨텍스트의 지식을 해당 캡슐화에 들어가는 것 (기능 매개 변수와 같은)으로 제한합니다.

고성능을 위해 글을 작성할 때 알고리즘 수정을 수정 한 후 컨텍스트에 대해 훨씬 더 많은 지식이 필요한 세부 정보를 얻을 수 있습니다. 그것은 작업에 충분히 집중하지 못하는 프로그래머를 당연히 압도 할 수 있습니다.

최적화되지 않은 코드를 실행하는 데 필요한 지구 온난화 비용 (수억 대의 PC와 대규모 데이터 센터 시설에 의해 확장 된 추가 CPU주기 및 사용자의 모바일 장치)의 평범한 배터리 수명으로 인해 대부분의 경우 거의 나타나지 않습니다. 프로그래머의 성능 또는 동료 리뷰.

무시되는 오염의 형태와 비슷한 경제적 부정적인 외부 효과입니다. 따라서 성과에 대한 사고의 비용 / 이익 비율은 실제로는 정신적으로 왜곡되어 있습니다.

하드웨어 설계자들은 최신 CPU에 절전 및 클록 스케일링 기능을 추가하기 위해 열심히 노력하고 있습니다. 사용 가능한 모든 CPU 클록 사이클을 씹지 않음으로써 하드웨어가 이러한 기능을 더 자주 활용할 수 있도록하는 것은 프로그래머에게 달려 있습니다.

추가 : 고대에는 한 대의 컴퓨터 비용이 수백만 달러 였으므로 CPU 시간을 최적화하는 것이 매우 중요했습니다. 그런 다음 코드 개발 및 유지 관리 비용이 컴퓨터 비용보다 높아 지므로 프로그래머 생산성에 비해 최적화가 유리하지 않았습니다. 그러나 이제 컴퓨터 비용보다 다른 비용이 증가하고 있으며, 모든 데이터 센터의 전원 공급 및 냉각 비용이 내부의 모든 프로세서 비용보다 높아지고 있습니다.

세 가지를 모두 달성하기는 어렵다고 생각합니다. 두 사람은 가능할 수 있다고 생각합니다. 예를 들어, 경우에 따라 효율성과 가독성을 얻을 수 있다고 생각하지만 미세 조정 된 코드로는 유지 관리가 어려울 수 있습니다. 지구상에서 가장 효율적인 코드 는 인텔이 인라인 어셈블리로 작성하는 손 SoA 벡터화, 멀티 스레드 SIMD 코드를 이해하거나 가장 자르지 않는 한 대부분의 사람들에게 명백한 것처럼 유지 관리 성과 가독성 이 모두 부족 합니다. 2 개월 전에 게시 된 40 페이지의 수학적 논문과 하나의 엄청나게 복잡한 데이터 구조를위한 12 개의 라이브러리가있는 업계에서 사용되는 첨단 알고리즘.

미세 효율

대중의 의견과 상반 될 수있는 한 가지 제안은 가장 똑똑한 알고리즘 코드가 가장 미세 조정 된 간단한 알고리즘보다 유지 관리가 더 어렵다는 것입니다. 확장 성 향상으로 마이크로 튜닝 된 코드 (예 : 캐시 친화적 액세스 패턴, 멀티 스레딩, SIMD 등)에 대한 벅에 더 많은 수익을 거둘 수 있다는 아이디어는 적어도 매우 복잡한 산업에서 일한 적이있는 도전입니다. 데이터 구조 및 알고리즘 (시각적 FX 산업), 특히 메시 처리와 같은 영역에서 강타가 클 수 있지만 새로운 알고리즘 및 데이터 구조를 도입 한 이후로 이전에 들어 본 적이없는 새로운 알고리즘 및 데이터 구조를 도입하면 비용이 매우 비쌉니다. 새로운. 또한, 나는

따라서 알고리즘 최적화가 항상 메모리 액세스 패턴과 관련된 최적화보다 우선한다는 아이디어는 항상 내가 동의하지 않은 것입니다. 물론 버블 정렬을 사용하는 경우 마이크로 최적화의 양이 도움이 될 수는 없지만 ... 이유가 항상 그렇게 명확하지 않다고 생각합니다. 그리고 알고리즘 최적화는 마이크로 최적화보다 유지하기가 더 어렵다. 예를 들어, 클래식하고 간단한 BVH 알고리즘을 사용하고 유체 시뮬레이션을 알고리즘 적으로 가속화하는 최첨단 방법을 위해 Dreamwork의 OpenVDB 코드보다 작은 부분을 미세 조정하는 Intel의 Embree가 유지 관리가 훨씬 쉽다는 것을 알았습니다. 그래서 저는 업계에서 인텔이 현장에 들어 섰을 때 컴퓨터 아키텍처에 익숙한 사람들이 더 많이 마이크로 최적화하는 것을보고 싶습니다. 수천 개의 새로운 알고리즘과 데이터 구조를 생각해내는 것과는 반대로 효과적인 마이크로 최적화를 통해 사람들은 잠재적으로 새로운 알고리즘을 발명해야하는 이유를 찾을 수 있습니다.

거의 모든 단일 사용자 작업에 고유 한 데이터 구조와 그 뒤에 알고리즘이있는 레거시 코드베이스에서 근무했습니다 (수백 가지의 이국적인 데이터 구조 추가). 그리고 그들 대부분은 성능 특성이 매우 왜곡되어 매우 좁게 적용되었습니다. 시스템이 더 광범위하게 적용 가능한 수십 개의 데이터 구조를 중심으로 회전 할 수 있다면 훨씬 쉬웠을 것입니다. 캐시 미스와 관련된 엄격한 읽기 전용 목적으로도 안전하게 사용할 수없는 수백 개의 마이크로 페시 화 된 데이터 구조 간의 차이를 의미하는 경우 마이크로 최적화가 유지 보수성을 크게 향상시킬 수 있기 때문에이 사례를 언급했습니다. 맞은 대.

기능적 언어

한편 내가 만난 가장 유지 보수가 쉬운 코드 중 일부는 기능적 언어로 작성 되었기 때문에 상당히 효율적이지만 읽기가 매우 어려웠습니다. 일반적으로 가독성과 uber 유지 관리 성은 상충되는 아이디어입니다.

코드를 한 번에 읽기 쉽고 유지 관리 가능하며 효율적으로 만드는 것은 정말 어렵습니다. 일반적으로 유지 보수성에 대한 가독성 저하 또는 효율성에 대한 유지 보수성 저하와 같이 둘 중 하나는 아니지만 둘 중 하나에서 조금 타협해야합니다. 일반적으로 다른 두 가지를 많이 찾으면 유지 관리가 용이합니다.

가독성 대 유지 관리

이제 말했듯이 가독성과 유지 관리 성은 조화로운 개념 이 아니라고 생각 합니다. 결국, 대부분의 필사자들에게 가장 읽기 쉬운 코드는 인간의 사고 패턴에 매우 직관적으로 매핑되며, 인간의 사고 패턴은 본질적으로 오류가 발생하기 쉽습니다. " 이런 일이 발생하면 이렇게하십시오. 그렇지 않으면 그렇게하십시오. 그렇지 않으면 그렇게하십시오. 이 시스템이 서로 상호 작용하는 경우이 시스템이이를 수행 할 수 있도록 이런 상황이 발생해야합니다 ... 오,이 이벤트가 트리거 될 때 해당 시스템은 어떻습니까?"나는 정확한 인용문을 잊었지만 누군가 로마가 소프트웨어처럼 지어 졌다면, 벽에 새가 내려 앉아 넘어 질 것이라고 생각했다. 대부분의 소프트웨어가 그런 경우이다. 우리가 자주 걱정하는 것보다 더 연약하다. 겉보기에 무해한 몇 줄의 코드가 여기에 있으며 전체 디자인을 다시 생각하게 만드는 시점까지 중단시킬 수 있습니다. 가능한 한 읽기 쉬운 것을 목표로하는 고급 언어는 그러한 인간 디자인 오류에 대한 예외가 아닙니다. .

순수한 기능적 언어는 실현 가능할 정도로 접근하기 어려운 수준에 가깝습니다 (취약점에 가깝지는 않지만 대부분에 비해 상대적으로 더 가깝습니다). 그것은 부분적으로 인간의 생각에 직관적으로 매핑되지 않기 때문입니다. 읽을 수 없습니다. 그들은 가능한 최소한의 지식을 사용하고 부작용을 일으키지 않고 가능한 한 적은 특수 사례로 문제를 해결해야하는 사고 패턴을 우리에게 강요합니다. 그것들은 매우 직교하며, 코드를 놀라게하지 않고 자주 변경하고 변경할 수 있기 때문에 모든 것을 다시 쓰지 않고도 전반적인 디자인에 대한 생각을 바꾸는 시점까지 드로잉 보드의 디자인을 다시 생각해야합니다. 그것보다 유지하기가 쉽지 않은 것 같습니다 ...하지만 코드는 여전히 읽기가 어렵습니다.

한 가지 문제는 개발자 시간이 제한되어 있기 때문에 최적화하려는 모든 것이 다른 문제에 대한 시간을 낭비하지 않는다는 것입니다.

Meyer 's Code Complete에 언급 된 것에 대해서는 다소 좋은 실험이 있습니다. 서로 다른 개발자 그룹에게 속도, 메모리 사용량, 가독성, 견고성 등을 최적화하도록 요청했습니다. 그들의 프로젝트는 그들이 최적화하도록 요청받은 모든 것에서 높은 점수를 받았지만 다른 모든 자질은 낮았습니다.

숙련 된 프로그래머가 사실임을 알게 되었기 때문입니다.

우리는 간결하고 의미가 있으며 성능 문제가없는 코드로 작업했습니다.

우리는 성능 문제를 해결하기 위해 매우 복잡한 많은 코드를 연구했습니다.

명심해야 할 한 가지 예는 마지막 프로젝트에 수동으로 샤딩 된 SQL 테이블 8,192 개가 포함되어 있다는 것입니다. 이것은 성능 문제로 인해 필요했습니다. 1 개의 테이블에서 선택하는 설정은 8,192 개의 샤드에서 선택하고 유지하는 것보다 훨씬 간단합니다.

고도로 최적화 된 코드는 읽고 이해하기 어려운 경우를 지원하는 대부분의 사람들의 두뇌를 구부리는 유명한 코드가 있습니다.

내가 생각하는 가장 유명한 것은 다음과 같습니다. Quake III Arena에서 가져와 John Carmak에 의한 것이지만,이 기능은 여러 번 반복되어 처음에는 그 기능에 의해 생성 된 것이 아니라고 생각 합니다.

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
    //      y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}