개발 초기 또는 종료시 성능을 향상시키기 위해 소프트웨어를 최적화하는 것이 언제 더 좋습니까?

저는 주니어 소프트웨어 개발자이며 더 나은 성능 (속도)을 위해 소프트웨어를 최적화하기 가장 좋은시기가 언제인지 궁금했습니다.

소프트웨어가 관리하기에 극히 크거나 복잡하지 않다고 가정 할 때, 최적화를 시작하는 데 더 많은 시간을 소비하는 것이 더 좋습니까? 아니면 모든 기능을 올바르게 실행하는 소프트웨어를 개발 한 다음 더 나은 성능을 위해 소프트웨어를 계속 진행해야합니까?

가장 중요한 것은 항상 그리고 영원히 가독성이어야합니다. 느리지 만 읽을 수 있으면 고칠 수 있습니다. 깨졌지만 읽을 수 있으면 고칠 수 있습니다. 읽을 수 없으면 다른 사람에게 이것이 무엇을해야하는지 물어봐야합니다.

읽을 수있는 데에만 집중할 때 코드 성능이 얼마나 뛰어난지를 알 수 있습니다. 너무 많은 관심을 가질 때까지 나는 일반적으로 성능을 무시합니다. 속도에 신경 쓰지 않는다는 의미로 사용해서는 안됩니다. 나는한다. 방금 읽기가 어려울 때 솔루션이 실제로 더 빠른 문제는 거의 없다는 것을 알았습니다.

이 모드에서 두 가지만 나옵니다.

1. 내가 큰 O 개선 의 기회를 보았을 때 , 심지어 n 이 누군가가 돌볼만큼 충분히 클 때만 .
2. 실제 성능 문제를 보여주는 테스트가있을 때 수십 년의 경험에도 불구하고 나는 여전히 수학보다 더 많은 시험을 신뢰합니다. 그리고 나는 수학을 잘합니다.

어쨌든 솔루션이 가장 빠르지 않기 때문에 시도하지 말아야한다고 생각하여 분석 마비 를 피 하십시오. 변경을하면 변경하기 쉬운 디자인을 사용해야하기 때문에 여러 솔루션을 시도하면 실제로 코드에 도움이됩니다. 유연한 코드베이스는 나중에 필요할 때 더 빨리 만들 수 있습니다. 속도보다 유연한 속도를 선택하면 필요한 속도를 선택할 수 있습니다.

특정 수준의 성능이 필요한 경우 (비 기능적 요구 사항), 처음부터 설계 목표가되어야합니다. 예를 들어, 이는 어떤 기술이 적절할 것인지 또는 프로그램에서 데이터 흐름을 구성하는 방법에 영향을 줄 수 있습니다.

그러나 일반적으로 코드를 작성하기 전에 최적화하는 것은 불가능합니다. 먼저 코드를 작동시킨 다음 올바르게 만들고 마지막으로 빠르게 만드십시오 .

대부분의 기능을 구현하기 전에 최적화하는 데있어 한 가지 큰 문제는 잘못된 위치에서 최적의 설계 결정을 내릴 수 없다는 것입니다. 유지 관리 성과 성능 간에는 종종 상충 관계가 있습니다. 프로그램의 대부분은 성능과 전혀 관련이 없습니다! 일반적인 프로그램에는 최적화 할 가치가있는 몇 가지 핫스팟 만 있습니다. 따라서 성능이 필요하지 않은 모든 장소에서 성능 유지 관리 성을 희생하는 것은 실제로 나쁜 거래입니다.

유지 보수성을 최적화하는 것이 더 나은 방법입니다. 당신이 지출하는 경우 영리를 유지 보수하고 명확한 디자인에, 당신은 중요한 부분을 식별하기 위해 장기적으로 더 쉽게 발견하고 안전하게 전체 디자인을 손상시키지 않고 그들을 최적화합니다.

더 나은 성능 (속도)을 위해 소프트웨어를 최적화하기에 가장 좋은시기는 언제입니까?

성능은 속도와 동일하다는 개념을 마음에서 제거하여 시작하십시오. 성능은 사용자가 성능을 믿는 것입니다 .

응용 프로그램이 마우스 클릭에 대해 두 배 빠른 속도로 응답하고 10 마이크로 초에서 5 마이크로 초로 이동하면 사용자는 신경 쓰지 않습니다. 응용 프로그램이 마우스 클릭에 대해 두 배 빠른 속도로 응답하고 4 천년에서 2 천년으로가더라도 사용자는 신경 쓰지 않습니다.

응용 프로그램을 두 배 빠르게 만들고 컴퓨터의 모든 메모리를 사용하여 충돌하면 사용자는 이제 두 배 빠른 속도를 신경 쓰지 않습니다.

성능은 특정 사용자 경험을 달성하기 위해 리소스 소비에 대한 효과적인 균형을 유지하는 과학입니다. 사용자의 시간은 중요한 자원 이지만 결코 "빠른"것은 아닙니다. 성능 목표를 달성하려면 거의 항상 절충이 필요하며, 종종 공간에 대한 시간을 절약하거나 그 반대의 경우도 있습니다.

소프트웨어가 관리하기에 너무 크거나 복잡하지 않다고 가정

그것은 끔찍한 가정입니다.

소프트웨어가 크거나 관리하기가 복잡하지 않으면 사용자가 관심을 갖는 흥미로운 문제를 해결하지 못할 수 있으며 최적화하기가 매우 쉽습니다.

최적화를 시작할 때 더 많은 시간을 소비하는 것이 더 좋습니까? 아니면 모든 기능을 올바르게 실행하는 소프트웨어를 개발 한 다음 더 나은 성능을 위해 최적화해야합니까?

당신은 빈 페이지에 앉아 있고 당신은 쓴다 void main() {}당신은 최적화를 시작합니까? 최적화 할 것이 없습니다! 올바른 순서는 다음과 같습니다.

• 컴파일 시키십시오
• 올바른지 확인하십시오
• 우아하게
• 빨리 해

다른 순서로 시도하면 엉망인 잘못된 코드가 생겨나므로 이제는 신속하게 잘못된 답변을 생성하고 변경에 저항하는 프로그램이 있습니다.

그러나 거기에는 한 걸음도 빠졌습니다. 실제 올바른 순서는 다음과 같습니다

• 고객 및 관리 부서와 협력하여 현실적이고 측정 가능한 성능 지표 및 목표를 설정하십시오. 속도는 고객이 관심을 갖는 유일한 지표가 아니라는 점을 기억하십시오.
• 목표와 비교하여 프로젝트의 현재 상태를 추적 할 수있는 테스트 장치를 구현하십시오.
• 컴파일 시키십시오
• 테스트를 실행하십시오. 더 이상 목표를 달성하지 못한 경우 일찍 나쁜 길을 갔을 수 있습니다. 과학을 사용하십시오 . 고칠 수있는 잘못된 알고리즘을 도입 했습니까, 아니면 근본적으로 잘못된 것입니까? 기본적으로 잘못된 경우 다시 시작하십시오. 문제가 해결되면 버그를 입력하고 나중에 다시 방문하십시오.
• 올바른지 확인하십시오
• 테스트를 다시 실행하십시오 ...
• 우아하게
• 테스트를 다시 실행하십시오 ...
• 목표를 준수하고 있습니까? 그렇다면 해변으로 가십시오 . 그렇지 않은 경우 충분히 빨리 만드십시오 .

일반적으로 나중에 성능을 최적화하는 것이 가장 좋지만, 개발자가 상당한로드 나 데이터가 추가 될 때 속도가 느려지는 소프트웨어로 인해 개발자가 프로젝트를 끝냈다는 것을 알게되면 많은 프로젝트가 나빠지는 것을 보았습니다.

따라서 제 생각에는 중간 접근 방식이 가장 좋습니다. 너무 강조하지는 않지만 성능을 완전히 무시하지는 마십시오.

여러 번 본 사례를 보여 드리겠습니다. ORM 라이브러리가 주어지면 하나 이상의 주문을 가질 수있는 사용자 엔티티가 있습니다. 사용자에 대한 모든 주문을 반복하고 사용자가 매장에서 소비 한 금액을 알아 봅니다. 순진한 접근 방식입니다.

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

필자는 개발자가 의미를 전혀 생각하지 않고 비슷한 내용을 작성하는 것을 보았습니다. 먼저 User 테이블에서 하나의 SQL 쿼리 일 것입니다 (그러나 훨씬 더 많은 것을 포함 할 수 있음). 그런 다음 주문을 반복합니다. , 제품 정보 등-이 모든 것은 각 주문에 대해 단일 정수를 얻는 것입니다!

여기에서 SQL 쿼리의 양은 당신을 놀라게 할 수 있습니다. 물론 엔터티가 어떻게 구성되어 있는지에 달려 있습니다.

여기에 올바른 접근 방식은 가능성이 가장 높은 ORM에서 제공하는 쿼리 언어로 작성된 별도의 쿼리를 통해 데이터베이스에서 합계를 얻기 위해 별도의 기능을 추가하는 것입니다, 나는이에게 일을 옹호 할 주위에 처음으로 ,이를 연기하지 나중에; 그렇게하면 돌봐야 할 더 많은 문제가 생길 수 있고 어디서부터 시작해야할지 확신 할 수 없기 때문입니다.

전체 시스템 성능은 시스템 구성 요소 전체의 복잡한 상호 작용의 산물입니다. 비선형 시스템입니다. 따라서 성능은 구성 요소의 개별 성능뿐만 아니라 이들 사이의 병목 현상 에 의해 좌우 됩니다.

시스템의 모든 구성 요소가 아직 구축되지 않은 경우 병목 현상을 테스트 할 수 없으므로 초기에 실제로 테스트 할 수는 없습니다. 반면에 시스템을 구축 한 후에는 원하는 성능을 얻기 위해 필요한 변경 작업을 수행하기가 쉽지 않을 수 있습니다. 이것이 골조 Catch-22 입니다.

문제를보다 어렵게 만들기 위해 프로덕션 환경과 같은 환경으로 전환하면 성능 프로필이 크게 변경 될 수 있습니다.

그래서 당신은 무엇을합니까? 글쎄, 몇 가지.

1. 실용적이 되십시오. 초기에는 성능에 "모범 사례"인 플랫폼 기능을 사용하도록 선택할 수 있습니다. 예를 들어, 연결 풀링, 비동기 트랜잭션 및 상태 저장 방지를 활용하십시오. 이는 여러 작업자가 공유 데이터에 액세스하기 위해 경쟁하는 다중 스레드 응용 프로그램의 죽음 일 수 있습니다. 일반적으로 이러한 패턴의 성능을 테스트하지 않고 경험을 통해 잘 작동하는 것을 알 수 있습니다.

2. 반복하십시오. 시스템이 비교적 새로운 경우에는 기준 성능 측정을 수행하고 새로 도입 된 코드가 성능을 크게 저하시키지 않는지 가끔 테스트를 다시 수행하십시오.

3. 조기에 지나치게 최적화하지 마십시오. 중요한 것이 무엇이고 중요하지 않은 것은 결코 모른다. 예를 들어 초고속 문자열 파싱 알고리즘은 프로그램이 지속적으로 I / O를 기다리는 경우 도움이되지 않을 수 있습니다.

4. 특히 웹 응용 프로그램에서는 성능이 아니라 확장성에 중점을 둘 수 있습니다. 응용 프로그램이 확장 될 수있는 경우 팜에 노드가 충분히 빠를 때까지 노드를 계속 추가 할 수 있으므로 성능은 거의 중요하지 않습니다.

5. 데이터베이스에 특별한주의를 기울입니다. 트랜잭션 무결성 제약 조건으로 인해 데이터베이스는 시스템의 모든 부분을 지배하는 병목 현상이 발생하는 경향이 있습니다. 고성능 시스템이 필요한 경우 데이터베이스 측에서 작업하고 쿼리 계획을 검토하며 가능한 일반적인 작업을 효율적으로 수행 할 테이블 및 인덱스 구조를 개발하는 재능있는 인력이 있는지 확인하십시오.

이러한 활동의 ​​대부분은 프로젝트의 시작이나 끝을위한 것이 아니라 지속적으로 참석해야합니다 .

저는 주니어 소프트웨어 개발자이며 더 나은 성능 (속도)을 위해 소프트웨어를 최적화하기 가장 좋은시기가 언제인지 궁금했습니다.

두 가지 극단이 있다는 것을 이해하십시오.

첫 번째 극단은 작업을 몇 개의 프로세스 및 / 또는 스레드로 분할하고 조각이 통신하는 방법 (TCP / IP 소켓? 직접 함수 호출?), 고급 JIT 구현 여부와 같이 디자인의 많은 부분에 영향을 미치는 것입니다. 또는 "한 번에 하나의 opcode"인터프리터, 또는 SIMD에 적합하도록 데이터 구조를 계획할지 여부, 또는 ... 이러한 것들이 구현에 큰 영향을 미치는 경향이 있으며, 이후에 개조하기가 지나치게 어려워 지거나 비용이 많이 드는 경향이 있습니다.

다른 극단은 미세 최적화입니다. 사방에 약간의 미세 조정이 있습니다. 이러한 것들은 구현에 거의 영향을 미치지 않는 경향이 있으며 (그리고 종종 컴파일러에 의해 가장 잘 수행됨), 필요할 때마다 이러한 최적화를하는 것은 사소한 일입니다.

이 극단 사이에는 커다란 회색 영역이 있습니다.

그것이 실제로 내려 오는 것은 "비용이 정당화 되는가?"라는 질문에 대답하기 위해 사용되는 경험 / 교육 된 추측입니다. 잘못 생각하는 경우 극한의 최적화를 위해 모든 작업을 중단하고 처음부터 다시 시작하거나 프로젝트 실패 (불필요하게 지나치게 복잡한 설계에 너무 많은 시간을 소비)를 다시 시작해야합니다. 다른 극단에서는 측정 (예 : 프로파일 링)을 사용하여 문제가 있음을 증명할 수있을 때까지 그대로 두는 것이 더 합리적입니다.

불행히도 우리는 너무 많은 사람들이 최적화에 "사소한"극단의 (대부분 관련이없는) 것들만 포함한다고 생각하는 세상에 살고 있습니다.

성능이 우수하거나 유지 관리가 불가능한 코드를 작성하는 것이 가장 쉽습니다. Porformant 코드를 작성하는 것이 더 어렵습니다. 유지 관리 가능한 코드를 작성하는 것은 아직 어렵습니다. 또한 유지 관리 가능하고 성능이 뛰어난 코드를 작성하는 것이 가장 어렵습니다.

그러나 수행 가능한 코드를 유지 관리하는 것보다 유지 관리 가능한 코드를 수행하는 것이 더 쉽습니다.

이제는 시스템 유형에 따라 다르며 일부 시스템은 성능이 크게 중요하며 처음부터 계획된 시스템이 필요합니다. 위에서 대답 한 Eric Lippert와 같은 매우 재능있는 사람들에게는 이러한 시스템이 일반적 일 수 있습니다. 그러나 대부분의 사람들은 우리가 구축 한 시스템의 소수입니다.

그러나 대부분 의 시스템 에서 최신 하드웨어 상태를 고려할 때 처음부터 최적화에 특별한주의를 기울일 필요는 없지만 일반적으로 성능 파괴를 피하는 것으로 충분합니다. 내가 의미하는 바는 단순히 쿼리 대신 카운트를 얻기 위해 테이블의 모든 레코드를 다시 가져 오는 것과 같이 멍청한 일을 피하는 것 select count(*) from table입니다. 실수를 피하고 사용중인 도구를 이해하려고 노력하십시오.

다음으로 코드 유지 관리에 중점을 둡니다. 이것은 다음을 의미합니다.

1. 우려 사항을 최대한 엄격하게 분리하십시오 (예 : 데이터 액세스와 비즈니스 로직을 혼용하지 마십시오)
2. 가능한 경우 구체적인 유형 대신 추상 유형 참조
3. 코드 테스트 가능

통계가 필요할 때 유지 관리 가능한 코드를 훨씬 쉽게 최적화 할 수 있습니다.

다음으로, 코드에 많은 자동화 된 테스트 가 있는지 확인하십시오 . 여기에는 몇 가지 이점이 있습니다. 버그가 적을수록 필요할 때 최적화 할 시간이 길어집니다 . 또한 최적화를 수행 할 때 구현에서 버그를 훨씬 빨리 발견하므로 최상의 솔루션을 훨씬 빠르게 반복하고 찾을 수 있습니다.

자동화 된 배포 스크립트 및 스크립트 인프라는 성능 조정에 매우 유용합니다. 다시 한 번 더 빠르게 반복 할 수 있습니다. 다른 이점은 말할 것도 없습니다.

따라서 항상 그렇듯이 예외 (더 나은 식별을 위해서는 경험이 필요함)가 있지만 일반적으로 조언은 다음과 같습니다. 먼저 도구를 배우고 코딩 성능 병목 현상을 피하십시오. 둘째, 코드 유지 관리가 가능한지 확인하십시오. 셋째, 자동화 된 테스트. 넷째, 완전 자동화 된 배포. 이러한 작업이 완료된 후에 만 ​​최적화에 대해 걱정해야합니다.

이미지 처리 및 레이트 레이싱과 같은 성능이 매우 중요한 영역에서 일하는 편견이있을 수 있지만 여전히 "가능한 한 늦게" 최적화하고 싶습니다 . 요구 사항의 성능이 얼마나 중요한지에 관계없이 측정 후 사전보다 훨씬 많은 정보와 명확성이 항상 있습니다. 즉, 가장 효과적인 최적화조차도 그러한 지식을 얻은 후에 나중에 적용됩니다.

독특한 경우

그러나 때때로 "가능한 한 늦게" 는 특이한 경우에는 아직 초기 단계에 있습니다. 예를 들어 오프라인 렌더러와 이야기하는 경우 실제로 성능을 달성하는 데 사용하는 데이터 구조와 기술은 실제로 사용자 엔드 디자인에 영향을 미칩니다. 역겨운 소리가 들릴 수 있지만이 분야는 최첨단이며 성능이 매우 중요하므로 사용자는 특정 광선 추적기에 적용 할 수있는 최적화 기술 (예 : 복사 캐싱 또는 광자 매핑)에 특정한 사용자 엔드 컨트롤을 사용할 수 있습니다. 이미지가 렌더링 될 때까지 기다리는 데 시간이 걸리고 다른 사람들은 렌더링 전용 머신을 사용하여 렌더 팜을 임대하거나 소유하기 위해 막대한 돈을 버는 데 사용됩니다. 경쟁적인 오프라인 렌더러가 렌더링에 소요되는 시간을 크게 줄일 수 있다면 시간과 비용이 크게 줄어 듭니다. 이것은 시간의 5 % 단축이 실제로 사용자를 흥분시키는 일종의 영역입니다.

이러한 특별한 경우에는 렌더링 기술을 하나만 선택하여 나중에 최적화 할 수는 없습니다. 사용자 엔드 디자인을 포함한 전체 디자인은 사용하는 데이터 구조와 알고리즘을 중심으로하기 때문입니다. 여기에서 개인으로서의 강점과 약점 때문에 경쟁 솔루션을 제공하는 데 크게 영향을 미치기 때문에 다른 사람들에게 잘 작동하는 것만으로도 갈 수는 없습니다. Arnold의 주요 개발자의 사고 방식과 감각은 VRay에서 작업하는 것과는 매우 다른 접근법을 사용합니다. 그들은 반드시 장소 / 기술을 교환 할 수는없고 최고의 직업을 수행 할 수는 없습니다 (둘 다 산업 리더 임에도 불구하고). 실험, 프로토 타입 및 벤치 마크를 수행하고 원하는 것을 찾아야합니다. 실제로 판매 할 수있는 경쟁력있는 제품을 배송하려는 경우 최첨단 기술을 제공하는 것이 특히 좋습니다. 따라서이 특별한 경우에 성능 문제는 개발을 시작하기 전에 아마도 가장 중요한 문제 일 수 있습니다.

아직이 반드시 최적화의 위반 것을 "가능한 늦게 ' , 그것은 단지 "가능한 한 늦게로는 " 오히려 초기에 이러한 극단적이고 독특한 경우이다. 이러한 초기 성능 문제가 필요하지 않은 시점과시기를 파악하는 것이 개발자에게는 가장 큰 과제 일 것입니다. 최적화하지 않는 것은 개발자의 경력에서 배우고 배우는 데있어 가장 귀중한 것들 중 하나 일 수 있습니다. 그들의 반대 생산성에도 불구하고).

가능한 한 늦게

아마도 가장 어려운 부분은 그것이 의미하는 바를 이해하는 것입니다. 나는 아직도 배우고 있고 거의 30 년 동안 프로그래밍을 해왔다. 그러나 특히 제 삼십년 동안, 나는 그것이 그렇게 어렵지 않다는 것을 깨닫기 시작했습니다. 구현보다 디자인에 더 집중한다면 로켓 과학이 아닙니다. 나중에 디자인을 변경하지 않고 적절한 최적화를 위해 호흡 공간을 더 많이 확보할수록 나중에 최적화 할 수 있습니다. 그리고 점점 더 많은 생산성으로 인해 호흡 공간을 확보 할 수있는 그러한 디자인을 찾고 있습니다.

나중에 최적화하기 위해 호흡 실을 제공하는 디자인

이러한 유형의 디자인은 실제로 "상식"을 적용 할 수 있다면 대부분의 경우 달성하기 어렵지 않습니다. 개인적인 이야기로서 나는 취미로 시각 예술에 빠져 있습니다 (저는 아티스트가 자신의 요구를 이해하고 언어를 말할 수있는 소프트웨어를 프로그래밍하는 것이 다소 도움이된다는 것을 알게되었습니다). 그리고 2000 년대 초 Oekaki 애플릿을 사용하여 시간을 보냈습니다. 내 작품을 낙서하고 공유하고 다른 아티스트와 교류 할 수있는 빠른 방법으로 온라인으로

특히 제가 가장 좋아하는 사이트와 애플릿에는 성능 결함이 있습니다 (사소한 브러쉬 크기는 크롤링 속도가 느려질 수 있음). 그러나 매우 멋진 커뮤니티가있었습니다. 성능 문제를 해결하기 위해 작은 1 또는 2 픽셀 브러시를 사용하고 다음과 같이 내 작업을 낙서했습니다.

그 동안 나는 계속해서 성능 향상을위한 소프트웨어 제안을했으며, 메모리 최적화 및 알고리즘 등에 관한 기술적 인 제안을 발견했습니다. 그래서 그는 실제로 프로그래머인지 물었고 예라고 말했고 소스 코드 작업을 초대했습니다.

나는 소스 코드를 보았다 그래서 같은, 그것을 실행을 프로파일, 나의 공포에 그는 "추상적 픽셀 인터페이스"의 개념을 중심으로 소프트웨어를 설계했다 IPixel동적으로 모든의 최고 핫스팟 뒤에 근본 원인 었죠하는, 모든 단일 이미지의 모든 단일 픽셀에 대한 할당 및 디스패치. 그러나 추상화가 단일 추상 픽셀의 세분화 수준에서 작동 할 때 디자인이 가장 사소한 미세 최적화를 넘어서는 코너에 갇히게 되었기 때문에 전체 소프트웨어의 디자인을 다시 고려하지 않으면 서이를 최적화하는 실질적인 방법은 없었습니다. 모든 것은이 추상 픽셀에 달려 있습니다.

나는 이것이 "상식"에 위배된다고 생각하지만 분명히 개발자에게는 그 상식이 아니었다. 그러나 가장 기본적인 사용 사례조차도 거대한 군대 시뮬레이션에서 픽셀, 입자 또는 작은 단위와 같이 수백만으로 인스턴스화되는 세분화 된 수준에서 사물을 추상화하지 않는 것과 같습니다. 호의 IImage또는 (모든 이미지 / 픽셀 당신이 부피가 집계 수준에서 필요한 형식을 처리 할 수 있습니다) IParticleSystem에 IPixel또는 IParticle, 다음은 가장 기본적이고 빠른에 쓰기 및 인터페이스 뒤에 구현을 간단하게 이해-및 넣을 수 있습니다 전체 소프트웨어 디자인을 다시 고려하지 않고 나중에 최적화해야 할 모든 호흡 공간을 확보하십시오.

그리고 그것이 요즘 내가 본 목표입니다. 위의 오프라인 렌더러와 같은 특수한 경우를 제외하고 가능한 한 많은 후시 정보 (측정 포함)를 사용하여 최대한 늦게 최적화 할 수있는 충분한 호흡 공간을 설계하고 가능한 한 늦게 필요한 최적화를 적용하십시오.

물론 필자는 일반적인 사용자 엔드 사례에서 사소한 크기에 쉽게 도달하는 입력에서 2 차 복잡성 알고리즘을 사용하여 시작하는 것을 제안하지는 않습니다. 어쨌든 누가 그런가요? 그러나 구현이 나중에 쉽게 교체 할 수 있다면 그렇게 큰 문제라고 생각하지 않습니다. 디자인을 재고하지 않아도 여전히 큰 실수는 아닙니다.

해당 성능이 애플리케이션에 의미하는 바에 따라 다릅니다. 응용 프로그램이 기능적으로 완성되기 전에 성능을 최적화 할 수 있는지 여부

가장 좋은 방법이 없을 때까지는 걱정하지 않아도되지만 특정 수준의 성능이 응용 프로그램의 성공에 중요 할 수 있습니다. 이 경우에 쉽지 않은 것으로 생각되면 "실패"를 위해 성능을 살펴 봐야합니다.

모든 프로젝트의 중요한 원칙은 먼저 어려운 부분에 집중하는 것입니다. 그렇게하면 할 수없는 것으로 판명되면 일찍 알게되고 완전히 다른 것을 시도 할 시간이 있거나 프로젝트에 너무 많은 시간을 소비하기 전에 프로젝트가 취소 될 수 있습니다.

성능이 속도 이상의 것을 제안합니다. 규모 (수백 ~ 수천 명의 동시 사용자)가 포함됩니다. 프로덕션로드를받을 때 응용 프로그램이 탱크에 들어 가지 않게해야합니다. 성능에는 응용 프로그램이 소비하는 리소스 (예 : 메모리) 양이 포함됩니다.

성능도 사용하기 쉽습니다. 일부 사용자는 1 초에 2 번의 키 입력으로 작업을 수행하는 것보다 10 초 동안 1 번의 키 입력 작업을 수행하려고합니다. 그런 것들에 대해서는 디자인 책임자에게 문의하십시오. 나는 이런 것들을 사용자에게 일찍 가져 가고 싶지 않습니다. 진공 상태에서는 X라고 말할 수 있지만 일단 기능 시험판으로 작업하면 Y라고 말할 수 있습니다.

가장 좋은 개별 속도는 데이터베이스 연결과 같은 자원을 보유하는 것입니다. 그러나 규모에 따라 연결을 가능한 한 늦게 확보하고 가능한 빨리 연결을 해제해야합니다. 데이터베이스로 3 회 이동하는 것이 3 회 개별 데이터베이스 이동보다 빠릅니다.

세션 중에 변경되지 않은 정보를 여행하고 있습니까? 그렇다면 세션 시작시 가져오고 메모리입니다.

수집 유형을 선택할 때는 기능, 속도 및 크기를 고려하십시오.

컬렉션에 아이템을 보관해야합니까? 일반적인 문제는 파일의 모든 줄을 목록으로 읽은 다음 한 번에 한 줄씩 목록을 처리하는 것입니다. 한 번에 한 줄씩 파일을 읽고 목록을 건너 뛰는 것이 훨씬 더 효율적입니다.

한 번 반복하고 세 가지 일을 할 수있을 때 세 번 반복합니다.

콜백을 통해 다른 스레드에서 처리해야 할 지점이 있습니까? 그렇다면 즉각적인 설계 요구를 방해하지 않는 경우 코드를 가능한 필요에 맞게 패키지하십시오.

많은 성능도 깨끗한 코드입니다.

조기 최적화가 있으며 실제로 더 많은 시간이 걸리지 않는 상식적인 작업을 수행하고 있습니다.

데이터베이스에서 조기 최적화를 볼 수 있습니다. 속도 문제가 발생하기 전에 속도가 정상화되지 않습니다. 내가 얻는 논쟁은 나중에 테이블을 변경하면 모든 것을 변경해야한다는 것입니다. 종종 그런 식으로 데이터를 표시하는 뷰를 작성할 수 있으며 나중에 비정규 화 된 테이블을 위해 스왑해야 할 수도 있습니다.