'최적화 코드'== '구조화 데이터'는 언제입니까?

ycombinator의 최근 기사 에는 훌륭한 프로그래머의 원칙이 담긴 의견이 나와 있습니다.

#7. 좋은 프로그래머 : 코드를 최적화합니다. 더 나은 프로그래머 : 나는 데이터를 구조화한다. 최고의 프로그래머 : 차이점은 무엇입니까?

주관적이고 논쟁적인 개념을 인정하는 사람-이것이 무엇을 의미하는지에 대한 입장이 있습니까? 나는하지만 나중에 대답을 소홀히하지 않기 위해 내 생각 으로이 질문을 편집하고 싶습니다.

코드 / 모델을 잘 구성하면 열 번 중 아홉 번 최적화가 명확 해집니다. 몇 번이나 당신은 호넷 둥지를 보았고 그것을 완전히 차선책으로 보았습니다. 그곳을 재구성 할 때 많은 중복이 매우 분명해졌습니다.

디자이너는 추가 할 것이 없을 때가 아니라 제거해야 할 것이 없을 때 완벽 함을 달성했다는 것을 알고 있습니다. -앙투안 드 생 텍쥐페리

잘 구조화 된 시스템은 본질적으로 최소가 될 것입니다. 최소의 특성으로 인해 시스템이 얼마나 적은지에 따라 목표를 달성하는 데 얼마나 적은지가 직접 관련되어 있기 때문에 최적화됩니다.

편집 : 다른 사람 이이 점에서 벗어난 점을 설명하기 위해 코드와 데이터 간의 관계를 식별하는 것으로 진술을 보는 것이 완전히 정확합니다. 따라서 관계는 다음과 같습니다. 데이터 구조를 변경하는 경우 변경된 구조를 존중하도록 코드를 변경해야합니다. 코드를 최적화하려는 경우 코드가 데이터를보다 최적으로 처리 할 수 ​​있도록 데이터 구조를 변경해야 할 가능성이 있습니다.

즉, 여기에는 완전히 별개의 가능성이 있으며, YCombinator와 관계가있는이 동료는 LISP의 동질성에 관한 코드 AS 데이터를 참조 할 수 있습니다. 이것은 내 마음의 의미로 이것을 추측하기위한 스트레칭이지만 YCombinator이므로 LISPers가 "최고의 프로그래머"라고 말하고 있다는 것을 배제하지는 않습니다.

필자는 저자가 데이터를 재구성하면 코드를 재구성하는 것을 암시한다고 생각합니다. 따라서 시스템 최적화를 목표로 데이터를 재구성하면 "차이점은 무엇입니까?"라는 메시지가 표시되면서 코드를 최적화해야합니다. 응답.

"우월한 프로그래머"는 "차이점은 무엇입니까?"라고 대답 할 수 있습니다. CPU 캐시 사용 개선을 위해 최적화를 시작한 후에는 데이터 구조의 레이아웃을 동일하게 유지할 수 있지만 액세스 순서를 변경하면 많은 부분을 처리 할 수 ​​있습니다. 차.

"사용자 데이터 검색이 너무 느립니다!"의 가장 확실한 예를 생각해보십시오.

사용자 데이터가 색인화되거나 정렬되지 않은 경우 데이터를 재구성하면 코드 성능이 빠르게 향상됩니다. 데이터가 올바르게 구조화되어 있고 인덱스를 사용하거나 이진 검색과 같은 작업을 수행하지 않고 컬렉션을 반복하는 경우 코드를 수정하면 코드 성능이 향상됩니다.

프로그래머는 문제 해결사입니다. 알고리즘과 데이터 구조를 구분하는 것이 유용하지만 종종 독립적으로 존재할 수는 없습니다. 최고의 프로그래머는 이것을 알고 있으며 불필요하게 자신을 분리하지 않습니다.

나는 적어도 언급없이 진술에 동의하지 않습니다. 코딩은 일부 데이터 구조의 활용과 관련된 활동입니다. 데이터 구조는 일반적으로 코딩에 영향을 미칩니다. 내 의견으로는 둘 사이에 차이가 있습니다.

저자는 마지막 부분을 "최고의 프로그래머 : 나는 두 가지를 모두 최적화 한다 " 라고 썼어야한다고 생각한다 .

Algorithms + Data Structures = Programs 라는 훌륭한 책이 있습니다 (적어도 출판되었을 때) .

코드를 최적화하면 속도가 2 배, 때로는 10 배 또는 20 배까지 향상 될 수 있지만 그 정도에 달려 있습니다. 그것은 많은 것처럼 들릴 수 있으며, 프로그램 실행 시간의 75 %가 속도가 쉽게 두 배가 될 수있는 5 라인 루틴에서 소비된다면, 그러한 최적화는 가치가 있습니다. 다른 한편으로, 데이터 구조의 선택은 다수의 크기에 의해 실행 속도에 영향을 줄 수있다. RAM에 저장된 10,000,000 개의 항목 선형 링크 목록에서 키로 데이터를 조회하기 위해 초 최적화 된 코드를 실행하는 최신 초 최적화 된 다중 스레드 프로세서는 단순한 코드화 된 중첩 해시 테이블을 실행하는 훨씬 느린 프로세서보다 느립니다. 실제로, 데이터를 올바르게 배치했다면 1980 년대까지

그러나 효율적인 데이터 구조를 설계하려면 코드를 최적화하는 것보다 복잡한 트레이드 오프가 필요한 경우가 많습니다. 예를 들어, 대부분의 경우 데이터를 가장 효율적으로 액세스 할 수있는 데이터 구조는 빠른 업데이트를 허용하는 것보다 업데이트 효율성이 떨어지며 (때로는 수십 배), 가장 빠른 업데이트를 허용하는 구조는 가장 느린 액세스를 허용 할 수 있습니다. 또한, 많은 경우에, 큰 데이터 세트에 최적 인 데이터 구조는 작은 것보다 비교적 비효율적 일 수있다. 훌륭한 프로그래머는 다양한 데이터 구조를 구현하고 유지하는 데 필요한 프로그래머 시간과 이러한 경쟁 요소의 균형을 맞추고 적절한 균형을 유지할 수 있도록 노력해야합니다.

데이터 구조는 성능과 관련하여 많은 것을 이끌어냅니다. 우리는 이상적인 데이터 구조에 대한 선입관을 가지고 문제를 어렵고 오래 볼 수 있다고 생각하며, 이러한 사고의 맥락에서 (종종 유도에 의해) 최적의 증거를 만들 수 있다고 생각합니다. 예를 들어 정렬 된 목록을 배열에 넣고 요소를 삽입하는 비용과 같은 것을 평가하는 경우 평균적으로 각 삽입에 대해 배열의 1/2을 이동시켜야 할 수도 있습니다. 각 이진 검색 에 대해 log n 단계에서 일치하는 항목을 찾을 수 있습니다.

또는 데이터 구조에 대한 결정을 미루고 ( 조기 최적화를 피함 ) 들어오는 데이터와 사용할 컨텍스트, 데이터 크기, 지연 시간 및 사용자에게 중요한 메모리, 메모리 용량 vs. 우리가 알고 있거나 고안 할 수있는 데이터 표현과 함께 사용합니다.

정렬 및 검색과 같은 영역에는 알아야 할 것이 많습니다. 정말 위대한 프로그래머들이 오랫동안이 일을 해왔습니다. 이러한 문제를 잘 이해하는 것이 유용하며, 데이터 구조 클래스를 다운 그레이드 할 때보 다 더 많은 메소드를 알고 있다면 큰 도움이됩니다. 이진 트리는 메모리 사용을 높이는 대신 삽입 성능이 뛰어납니다. 해시 테이블 은 훨씬 더 큰 개선을 제공하지만 더 많은 메모리를 제공합니다. 기수 트리와 기수 정렬 은 더 향상 될 수 있습니다.

데이터를 창의적으로 구성하면 문제를 재구성하고 어려운 알고리즘을 더 빠르고 때로는 불가능한 작업을 수행 할 수있는 새로운 알고리즘의 문을 열 수 있습니다.

어떤 기사 수단에서 내 추측을 명확하게하기 위해, 나는 그 (기사에서 누락 된 것으로 보인다) 무언의 숨은 가정합니다 모든 프로그래머가 최적화에 대해 이해해야을 :

• 최적화는 프로그램을 시작하고 올바르게 실행 한 후에 만 ​​가능합니다.
  • 제대로 실행되도록, 다음 이 빠르게 실행되도록
  • 이 원칙은 Knuth의 최대 점입니다. "조기 최적화는 모든 악의 근원"
• 최적화가 조기에 이루어지지 않았다고 판단한 경우, 먼저 최적화가 실제로 필요한 것이 무엇인지 판별하고 최적화 중에 반복 하여 최적화 시도가 어떤 영향을 미치는지 판별하기 위해 먼저 올바르게 측정 해야합니다 .
  • 코드가 개발 중에 실행되면 프로파일 러가 이것의 친구입니다.
  • 코드가 프로덕션 환경에서 실행되는 경우 코드를 계측하고 대신 로깅 시스템과 친구가되어야합니다.

이제 측정 값은 코드에서 머신이 가장 많은 사이클을 레코딩하는 위치를 알려줍니다. "양호한"프로그래머는 관련없는 부분을 최적화하는 데 시간을 낭비하지 않고 코드 부분을 최적화하는 데 집중합니다.

그러나 시스템 전체를보고 기계가 적은 작업을 수행 할 수있는 방법을 찾으면 더 큰 이익을 얻을 수 있습니다. 종종 이러한 변경으로 인해 데이터 조직을 재 작업해야합니다. 따라서 "더 나은"프로그래머는 스스로 데이터를보다 자주 구성하는 것을 알게 될 것입니다.

"최고의 프로그래머"는 기계가 작동하는 방식, 알고리즘 설계에 대한 훌륭한 접지 및 상호 작용 방식에 대한 실질적인 이해에 대한 철저한 정신 모델을 갖게됩니다. 이를 통해 시스템을 통합 전체로 간주 할 수 있습니다. 코드를 최적화하는 것과 데이터를 아키텍처 수준에서 평가하기 때문에 데이터를 최적화하는 데 차이가 없습니다.

최고의 프로그래머 : 차이점은 무엇입니까?

최고의 프로그래머? 루시 프로그래머. "최적화"라는 단어는 프로그래머가 일반적으로 메모리, CPU 시간을 최적화하려고하는 것을 의미한다고 가정합니다. 이런 의미에서 최적화는 거의 모든 다른 소프트웨어 메트릭에 맞지 않습니다. 이해성, 유지 관리 성, 테스트 가능성 등 : 최적화하려는 목표가 사람의 이해 가능성, 유지 관리 성, 테스트 가능성 등이 아니라면 최적화가 목표 일 때 모두 짧은 시간이 소요됩니다. 비용은 말할 것도 없습니다. 속도 / 공간 최적 알고리즘을 작성하는 것은 일부 텍스트 나 저널에 제시된 알고리즘을 순진하게 코딩하는 것보다 개발자 시간 측면에서 훨씬 더 많은 비용이 듭니다. 형편없는 프로그래머는 그 차이를 모른다. 좋은 것입니다. 최고의 프로그래머는 정확히 무엇을 최적화해야하는지 판단하는 방법을 알고 있습니다.