이 사이트에는 이미 성능에 관한 질문이 많이 있지만, 거의 모든 것이 문제별로 다르고 상당히 좁습니다. 거의 모든 것이 조기 최적화를 피하기 위해 조언을 반복합니다.
가정하자 :
내가 여기서 찾고있는 것은 남은 일 외에는 아무것도하지 않을 때 중요한 알고리즘에서 마지막 몇 퍼센트까지 짜내는 전략과 요령입니다.
이상적으로는 언어에 구애받지 않고 대답을 시도하고 해당되는 경우 제안 된 전략에 대한 단점을 나타냅니다.
나는 자신의 초기 제안으로 답장을 추가하고 스택 오버플로 커뮤니티가 생각할 수있는 다른 것을 기대합니다.
답변:
좋아, 당신은 개선의 여지가별로없는 것처럼 문제를 정의하고 있습니다. 내 경험상 그것은 매우 드 rare니다. 나는 1993 년 11 월 Dr. Dobbs 기사에서 명백한 낭비가없는 기존의 잘 설계된 비 사소한 프로그램에서 시작하여 벽시계 시간이 48 초에서 단축 될 때까지 일련의 최적화를 통해 설명했습니다. 1.1 초로, 소스 코드 크기는 4 배 줄었습니다. 내 진단 도구 는 다음과 같습니다 . 변경 순서는 다음과 같습니다.
발견 된 첫 번째 문제점은 목록 클러스터 (현재 "반복자"및 "컨테이너 클래스")를 절반 이상 사용하는 것입니다. 그것들은 상당히 간단한 코드로 대체되어 시간이 20 초로 단축되었습니다.
이제 가장 큰 타임 테이커는 더 많은 목록 작성입니다. 백분율로 보면 이전에는 그리 크지 않았지만 이제는 더 큰 문제가 제거 되었기 때문입니다. 속도를 높이는 방법을 찾으면 시간이 17 초로 줄어 듭니다.
이제 명백한 범인을 찾기가 더 어렵지만, 내가 할 수있는 몇 가지 작은 것들이 있으며 시간은 13 초로 떨어집니다.
이제 벽에 부딪힌 것 같습니다. 샘플은 정확히 무엇을하고 있는지 알려주지 만 개선 할 수있는 것을 찾을 수없는 것 같습니다. 그런 다음 프로그램의 기본 디자인, 트랜잭션 중심 구조에 대해 생각하고 수행중인 모든 목록 검색이 실제로 문제의 요구 사항에 의해 지시되는지 묻습니다.
그런 다음 프로그램 코드가 더 작은 소스 세트에서 실제로 (전 처리기 매크로를 통해) 생성되고 프로그램이 프로그래머가 알고있는 것을 지속적으로 파악하지 못하는 재 설계에 착수했습니다. 다시 말해, 일련의 작업을 "해석"하지 말고 "컴파일"하십시오.
이제는 점점 빨라지기 때문에 샘플링하기가 어렵 기 때문에 10 배나 많은 작업을 수행하지만 다음 시간은 원래 작업량을 기준으로합니다.
더 많은 진단은 대기열 관리에 시간을 보내고 있음을 나타냅니다. 인라인으로 시간을 7 초로 줄입니다.
이제 큰 시간을 보냈다는 것은 내가하고 있던 진단 인쇄입니다. 플러시-4 초.
이제 가장 큰 타임 테이커는 malloc을 호출 하고 무료 입니다. 개체 재활용-2.6 초
계속해서 샘플을 보더라도 여전히 1.1 초라는 꼭 필요한 작업은 없습니다.
총 속도 향상 요소 : 43.6
이제 두 프로그램이 비슷하지는 않지만 장난감이 아닌 소프트웨어에서는 항상 이와 같은 진행 상황을 보았습니다. 먼저 수익이 줄어들 기 전까지는 쉬운 일을하고 더 어려운 일을합니다. 그렇다면 당신이 얻는 통찰력은 다시 디자인이 줄어들어 다시 줄어드는 수익에 도달 할 때까지 새로운 속도 향상을 시작합니다. 이제이이 있는지 궁금해에 적합 할 수 있습니다되는 지점입니다 ++i또는 i++또는 for(;;)또는 while(1)입니다 빨리 : 나는 스택 오버플로에 너무 자주 볼 질문의 종류.
PS 왜 프로파일 러를 사용하지 않았는지 궁금 할 것입니다. 이에 대한 답은 이러한 "문제"중 거의 모든 것이 샘플을 정확하게 찾아주는 함수 호출 사이트라는 것입니다. 오늘날에도 프로파일 러는 전체 함수보다 명령문 및 호출 명령이 위치를 찾고 수정하기가 더 중요하다는 생각을 거의 듣지 않고 있습니다.
실제로이 작업을 수행하기 위해 프로파일 러를 구축했지만 코드가 수행하는 작업에 대한 불길하고 친밀한 친밀감을 얻으려면 손가락을 바로 넣을 수 없습니다. 발견되는 문제가 너무 작아서 쉽게 놓칠 수 없기 때문에 샘플 수가 적다는 것은 문제가되지 않습니다.
추가 : jerryjvl이 몇 가지 예를 요청했습니다. 첫 번째 문제는 다음과 같습니다. 시간이 절반 이상 걸리는 소수의 개별 코드 줄로 구성됩니다.
/* IF ALL TASKS DONE, SEND ITC_ACKOP, AND DELETE OP */
if (ptop->current_task >= ILST_LENGTH(ptop->tasklist){
. . .
/* FOR EACH OPERATION REQUEST */
for ( ptop = ILST_FIRST(oplist); ptop != NULL; ptop = ILST_NEXT(oplist, ptop)){
. . .
/* GET CURRENT TASK */
ptask = ILST_NTH(ptop->tasklist, ptop->current_task)
이들은 목록 클러스터 ILST (목록 클래스와 유사)를 사용하고있었습니다. 그것들은 일반적인 방법으로 구현되며, "정보 숨기기"는 클래스 사용자가 구현 방식에 신경 쓸 필요가 없다는 것을 의미합니다. 이 줄이 작성되었을 때 (약 800 줄의 코드 중), 이것이 "병목 현상"(나는 그 단어를 싫어한다) 일 수 있다는 생각에 대해서는 생각하지 않았다. 그들은 단순히 일을하는 권장 방법입니다. 가급적이면 이러한 것들을 피해야한다고 말하기는 쉽지만 내 경험상 모든 성능 문제는 이와 같습니다. 일반적으로 성능 문제가 발생하지 않도록하는 것이 좋습니다. "피해야 했음"(후시)에도 생성 된 것을 찾고 수정하는 것이 더 좋습니다.
두 번째 문제는 두 줄로 나뉘어져 있습니다.
/* ADD TASK TO TASK LIST */
ILST_APPEND(ptop->tasklist, ptask)
. . .
/* ADD TRANSACTION TO TRANSACTION QUEUE */
ILST_APPEND(trnque, ptrn)
이들은 끝에 항목을 추가하여 건물 목록입니다. (수정은 항목을 배열로 수집하고 한 번에 목록을 작성하는 것이 었습니다.) 흥미로운 점은 이러한 문장이 원래 시간의 3/48에 불과하기 때문에 비용이 들지 않았다는 것입니다. 사실 처음 에는 큰 문제 입니다. 그러나 첫 번째 문제를 제거한 후 3/20의 시간이 소요되어 이제는 "더 큰 물고기"가되었습니다. 일반적으로 그렇게됩니다.
이 프로젝트가 내가 도와 준 실제 프로젝트에서 증류되었다고 덧붙일 수 있습니다. 이 프로젝트에서 내부 루프 내에서 데이터베이스 액세스 루틴을 호출하여 작업이 완료되었는지 확인하는 등 성능 문제가 훨씬 더 급격했습니다.
참고 ADDED : 소스 코드, 모두 원본과 재 설계는에서 찾을 수 있습니다 www.ddj.com 파일 9311.zip 파일 slug.asc 및 slug.zip에서, 1993.
2011/11/26 편집 : 이제 Visual C ++에 소스 코드가 포함 된 SourceForge 프로젝트 와 조정 방법에 대한 자세한 설명이 있습니다. 그것은 위에서 설명한 시나리오의 전반부를 통과하며 정확히 동일한 순서를 따르지 않지만 여전히 2-3 배의 속도 향상을 얻습니다.
제안 :
더 이상 성능을 향상시킬 수없는 경우 대신 인식 된 성능을 향상시킬 수 있는지 확인하십시오 .
fooCalc 알고리즘을 더 빨리 만들지 못할 수도 있지만 종종 응용 프로그램이 사용자에게보다 반응 적으로 보이도록하는 방법이 있습니다.
몇 가지 예 :
이렇게하면 프로그램이 더 빨라지지는 않지만 속도가 빨라지면 사용자가 더 행복해질 수 있습니다.
나는 대부분의 인생을이 곳에서 보냅니다. 광범위한 스트로크는 프로파일 러를 실행하고 기록하도록합니다.
__restrict앨리어싱에 대해 컴파일러에게 약속 하려면 자유로이 사용하십시오 .그리고 내가하고 싶은 한 가지 더 :
Examples on the PowerPC ...<-즉, PowerPC의 일부 구현입니다. PowerPC는 CPU가 아닌 ISA입니다.
lea.
더 많은 하드웨어를 던져라!
더 많은 제안 :
I / O 피하기 : 모든 I / O (디스크, 네트워크, 포트 등)는 항상 계산을 수행하는 코드보다 훨씬 느리므로 반드시 필요하지 않은 I / O를 제거하십시오.
I / O를 사전에 이동 : 계산에 필요한 모든 데이터를 사전에로드하여 중요한 알고리즘의 핵심 내에서 I / O 대기를 반복하지 않도록 (결과가 반복 될 수 있음) 디스크 검색 (한 번의 히트로 모든 데이터를로드 할 때 검색을 피할 수 있음).
I / O 지연 : 계산이 끝날 때까지 결과를 쓰지 말고 데이터 구조에 저장 한 다음 열심히 일할 때 한 번에 그 결과를 덤프하십시오.
스레드 I / O : 대담한 사람들을 위해,로드를 병렬 스레드로 이동하여 'I / O up-front'또는 'Delay I / O'를 실제 계산과 결합하여 더 많은 데이터를로드하는 동안 작업 할 수 있습니다 이미 보유한 데이터를 계산하거나 다음 데이터 배치를 계산하는 동안 마지막 배치의 결과를 동시에 쓸 수 있습니다.
mmap()입력에 사용 하고, 적절한 madvise()호출을 수행하고 , aio_write()큰 덩어리의 출력을 작성 하는 데 사용 하는 것입니다 (= MiB 몇 개).
많은 성능 문제는 데이터베이스 문제와 관련되므로 쿼리 및 저장 프로 시저를 조정할 때 살펴볼 특정 사항을 알려 드리겠습니다.
대부분의 데이터베이스에서 커서를 사용하지 마십시오. 루핑도 피하십시오. 대부분의 경우 데이터 액세스는 레코드 처리에 의한 레코드가 아니라 설정 기반이어야합니다. 여기에는 1,000,000 개의 레코드를 한 번에 삽입하려는 경우 단일 레코드 저장 프로 시저를 재사용하지 않는 것이 포함됩니다.
select *를 사용하지 말고 실제로 필요한 필드 만 반환하십시오. 조인 필드가 반복되어 서버와 네트워크 모두에 불필요한로드가 발생하기 때문에 조인이있는 경우 특히 그렇습니다.
상관 된 하위 쿼리를 사용하지 마십시오. 조인 (가능한 경우 파생 테이블에 대한 조인 포함)을 사용하십시오 (Microsoft SQL Server에서는 이것이 사실이지만 다른 백엔드를 사용할 때 조언을 테스트하십시오).
인덱스, 인덱스, 인덱스 데이터베이스에 해당되는 경우 해당 통계를 업데이트하십시오.
쿼리를 sargable로 만듭니다 . 의미는 like 절의 첫 문자에 와일드 카드를 사용하거나 조인의 함수 또는 where 문의 왼쪽 부분에 색인을 사용할 수없는 것을 피하십시오.
올바른 데이터 유형을 사용하십시오. 문자열 데이터 유형을 날짜 데이터 유형으로 변환 한 다음 계산을 수행하는 것보다 날짜 필드에서 날짜 계산을 수행하는 것이 더 빠릅니다.
어떤 종류의 루프도 트리거에 넣지 마십시오!
대부분의 데이터베이스에는 쿼리 실행 방법을 확인할 수있는 방법이 있습니다. Microsoft SQL Server에서는이를 실행 계획이라고합니다. 문제 영역이 어디에 있는지 먼저 확인하십시오.
최적화해야 할 사항을 결정할 때 쿼리 실행 빈도와 실행 시간을 고려하십시오. 때때로 한 달에 한 번만 실행되는 long_running 쿼리에서 시간을 지우는 것보다 약간의 조정에서 하루에 수백만 번 실행되는 쿼리까지 더 많은 성능을 얻을 수 있습니다.
어떤 종류의 프로파일 러 도구를 사용하여 데이터베이스에서 실제로 전송되는 내용을 찾으십시오. 과거에 저장 프로 시저가 빠를 때 웹 페이지가 한 번이 아니라 여러 번 쿼리를 요청하는 프로파일 링을 통해 페이지가로드되는 속도가 느린 이유를 알 수 없었던 적이 있습니다.
프로파일 러는 누가 누가 차단하고 있는지 찾는 데 도움을줍니다. 혼자 실행하는 동안 빠르게 실행할 일부 쿼리로 인해 다른 쿼리의 잠금에 정말 느린 될 수 있습니다.
오늘날 가장 중요한 제한 요소는 제한된 메모리 대역폭 입니다. 대역폭이 코어간에 공유되므로 멀티 코어는이를 더욱 악화시키고 있습니다. 또한 캐시 구현에 전념하는 제한된 칩 영역도 코어와 스레드로 나누어 져이 문제가 더욱 악화됩니다. 마지막으로, 서로 다른 캐시를 일관성있게 유지하는 데 필요한 칩 간 신호도 코어 수가 증가함에 따라 증가합니다. 이것은 또한 패널티를 추가합니다.
이것들은 관리해야 할 효과입니다. 때로는 코드를 미세하게 관리하지만 신중한 고려와 리팩토링을 통해서도 있습니다.
많은 의견에서 이미 캐시 친화적 인 코드를 언급하고 있습니다. 이것에는 적어도 두 가지 독특한 풍미가 있습니다.
첫 번째 문제는 특히 데이터 액세스 패턴을보다 규칙적으로 만들어 하드웨어 프리 페 처가 효율적으로 작동하는 것과 관련이 있습니다. 데이터 객체를 메모리에 분산시키는 동적 메모리 할당을 피하십시오. 연결된 목록, 해시 및 트리 대신 선형 컨테이너를 사용하십시오.
두 번째 문제는 데이터 재사용 개선과 관련이 있습니다. 사용 가능한 캐시에 맞는 데이터의 하위 집합에서 작동하도록 알고리즘을 변경하고 여전히 캐시에있는 동안 해당 데이터를 최대한 재사용하십시오.
데이터를보다 엄격하게 패킹하고 핫 루프에서 캐시 라인의 모든 데이터를 사용하면 이러한 다른 영향을 피하고 캐시에 보다 유용한 데이터를 맞출 수 있습니다.
Mike Dunlavey의 답변이 마음에 들지만 실제로는 지원 사례에 대한 훌륭한 답변이지만 실제로 매우 간단하게 표현할 수 있다고 생각합니다.
처음의 가장 큰 금액을 필요한 것을 알아보고 이유를 이해.
알고리즘을 세분화해야하는 위치를 이해하는 데 도움이되는 것은 시간 호그의 식별 프로세스입니다. 이것은 이미 완전히 최적화 된 문제에 대해 찾을 수있는 유일한 포괄적 인 언어 불가지론 적 답변입니다. 또한 속도를 추구하는 데 독립적 인 아키텍처를 원한다고 가정합니다.
알고리즘을 최적화 할 수있다 그래서 동안, 그것의 구현되지 않을 수 있습니다. 식별을 통해 알고리즘 또는 구현 중 어느 부분을 알 수 있습니다. 따라서 시간이 가장 많이 걸리는 사람이 검토 대상입니다. 그러나 마지막 몇 %를 짜내고 싶다고 말하면 처음에는 자세히 살펴 보지 않은 작은 부분도 검사해야 할 수 있습니다.
마지막으로 동일한 솔루션 또는 잠재적으로 다른 알고리즘을 구현하는 여러 가지 방법으로 성능 수치에 대한 약간의 시행 착오를 통해 시간 낭비와 시간 절약을 식별하는 데 도움이되는 통찰력을 얻을 수 있습니다.
HPH, asoudmove.
"Google Perspective"를 고려해야합니다. 즉, 애플리케이션이 크게 병렬화되고 동시화 될 수있는 방법을 결정해야합니다. 이는 어느 시점에서 애플리케이션을 다른 머신과 네트워크에 분산 시켜서 거의 선형으로 확장 할 수 있도록하는 것을 의미합니다. 던지는 하드웨어로
반면에 Google 직원은 전담 엔지니어 팀을 통해 gcc 에 대한 전체 프로그램 최적화 와 같이 사용중인 프로젝트, 도구 및 인프라의 일부 문제를 해결하는 데 많은 인력과 리소스를 투입하는 것으로도 유명합니다. Google의 일반적인 사용 사례 시나리오에 대비하기 위해 gcc 내부를 해킹합니다.
마찬가지로 응용 프로그램 프로파일 링은 더 이상 단순히 시스템 코드 관점에서 중복성과 최적화 가능성을 식별하기 위해 프로그램 코드뿐만 아니라 모든 주변 시스템 및 인프라 (네트워크, 스위치, 서버, RAID 어레이를 고려)를 프로파일 링하는 것을 의미합니다.
나누고 정복
처리중인 데이터 세트가 너무 큰 경우 청크를 반복하십시오. 코드를 올바르게 작성했다면 구현이 쉬워야합니다. 모 놀리 식 프로그램이 있다면 이제 더 잘 알 것입니다.
우선, 몇 가지 이전 답변에서 언급했듯이 메모리, 프로세서, 네트워크 또는 데이터베이스 또는 다른 것이 성능에 어떤 영향을 미치는지 알아보십시오. 그것에 따라 ...
... 메모리라면- "컴퓨터 프로그래밍의 예술"시리즈 중 하나 인 Knuth가 오래 전에 저술 한 책 중 하나를 찾으십시오. 정렬 및 검색에 관한 것일 가능성이 큽니다. 내 메모리가 잘못된 경우 느린 테이프 데이터 저장을 처리하는 방법에 대해 이야기해야합니다. 그의 메모리 / 테이프 쌍을 각각 캐시 / 메인 메모리 쌍 (또는 L1 / L2 캐시 쌍)으로 각각 변환하십시오. 그가 설명하는 모든 요령을 연구하십시오-문제를 해결할 수있는 것을 찾으면 전문 컴퓨터 과학자를 고용하여 전문 연구를 수행하십시오. 메모리 문제가 FFT에 의해 우연히 발생하는 경우 (기수 -2 나비를 수행 할 때 비트 반전 인덱스에서 캐시 누락) 과학자를 고용하지 말고 대신 수동으로 패스를 하나씩 최적화하십시오. 다시이기거나 막 다른 길로 가십시오. 당신은 언급마지막 몇 퍼센트까지 짜내 ? 그것이 실제로 소수 라면 당신이 이길 것입니다.
... 프로세서 인 경우-어셈블리 언어로 전환하십시오. 프로세서 사양 연구- 진드기 , VLIW, SIMD가 필요한 것. 함수 호출은 대체 가능한 틱 먹는 사람입니다. 루프 변환 배우기-파이프 라인, 언롤 곱셈과 나눗셈은 비트 시프트로 대체 가능 / 보간 될 수 있습니다 (작은 정수로 곱하면 덧셈으로 대체 가능). 더 짧은 데이터로 트릭을 시도하십시오-운이 좋으면 64 비트의 명령 하나가 32 비트의 2 개 또는 16 비트의 4 개 또는 8 비트의 8 비트로 대체 될 수 있습니다. 더 길게 시도데이터-예를 들어 플로트 계산은 특정 프로세서에서 두 배보다 느릴 수 있습니다. 삼각법이있는 경우 미리 계산 된 테이블과 싸워야합니다. 또한 정밀도 손실이 허용 한계 내에 있으면 작은 값의 사인이 해당 값으로 대체 될 수 있습니다.
... 네트워크 인 경우 데이터를 압축하는 것이 좋습니다. XML 전송을 이진으로 바꿉니다. 연구 프로토콜. 어떻게 든 데이터 손실을 처리 할 수 있으면 TCP 대신 UDP를 사용해보십시오.
... 데이터베이스라면 데이터베이스 포럼으로 가서 조언을 구하십시오. 인 메모리 데이터 그리드, 쿼리 계획 최적화 등
HTH :)
나는 이것이 이미 다른 방식으로 언급되었다고 생각합니다. 그러나 프로세서 집약적 알고리즘을 다룰 때는 다른 모든 것을 희생하면서 가장 내부 루프 내부의 모든 것을 단순화해야합니다.
일부 사람들에게는 분명해 보일지 모르지만, 내가 사용하는 언어에 관계없이 집중하려고하는 것입니다. 예를 들어 중첩 루프를 처리하고 일부 코드를 한 수준 아래로 내릴 수있는 기회를 찾는 경우 코드 속도를 크게 향상시킬 수 있습니다. 또 다른 예로서, 가능할 때마다 부동 소수점 변수 대신 정수로 작업하고 가능할 때마다 나누기 대신 곱셈을 사용하는 것과 같은 작은 생각이 있습니다. 다시, 이것들은 가장 내부 루프에 대해 고려해야 할 것들입니다.
내부 루프 내부의 정수에 대해 수학 연산을 수행 한 다음 나중에 작업 할 수있는 부동 소수점 변수로 축소하는 이점이 있습니다. 그것은 한 섹션에서 다른 섹션의 속도를 향상시키기 위해 속도를 희생하는 예이지만, 어떤 경우에는 그만한 가치가 있습니다.
저 대역폭 및 긴 대기 시간 네트워크 (예 : 위성, 원격, 해외)를 통해 작동하는 클라이언트 / 서버 비즈니스 시스템을 최적화하는 데 시간을 보냈으며 상당히 반복 가능한 프로세스로 성능을 크게 향상시킬 수있었습니다.
측정 : 네트워크의 기본 용량 및 토폴로지를 이해하여 시작합니다. 비즈니스에서 관련 네트워킹 담당자와 대화하고 핑 및 추적 경로와 같은 기본 도구를 사용하여 일반적인 운영 기간 동안 각 클라이언트 위치에서 네트워크 대기 시간을 설정합니다 (최소한). 다음으로, 문제가있는 증상을 나타내는 특정 최종 사용자 기능을 정확하게 시간 측정하십시오. 위치, 날짜 및 시간과 함께이 모든 측정 값을 기록하십시오. 최종 사용자 "네트워크 성능 테스트"기능을 클라이언트 응용 프로그램에 구축하여 고급 사용자가 개선 프로세스에 참여할 수 있도록하십시오. 이처럼 권한을 부여하는 것은있을 수 거대한 당신이 성능이 낮은 시스템에 의해 좌절 사용자를 처리 할 때 심리적 인 영향을.
분석 : 사용 가능한 모든 로깅 방법을 사용하여 영향을받는 작업을 실행하는 동안 전송 및 수신되는 데이터를 정확하게 설정합니다. 이상적으로 응용 프로그램은 클라이언트와 서버 모두에서 송수신하는 데이터를 캡처 할 수 있습니다. 여기에 타임 스탬프도 포함되어 있으면 더 좋습니다. 충분한 로깅을 사용할 수없는 경우 (예 : 닫힌 시스템 또는 프로덕션 환경에 수정 사항을 배포 할 수없는 경우) 네트워크 스니퍼를 사용하여 네트워크 수준에서 진행중인 작업을 실제로 이해해야합니다.
캐시 : 정적 또는 드물게 변경되는 데이터가 반복적으로 전송되는 경우를 찾고 적절한 캐싱 전략을 고려하십시오. 일반적인 예에는 "선택 목록"값 또는 기타 "참조 엔터티"가 포함되며 일부 비즈니스 응용 프로그램에서는 놀라 울 정도로 클 수 있습니다. 많은 경우에, 일반적으로 자주 사용되는 사용자 인터페이스 요소의 표시에서 상당한 시간을 줄일 수있는 경우, 사용자는 자주 업데이트되지 않는 데이터를 업데이트하기 위해 응용 프로그램을 다시 시작하거나 새로 고쳐야한다는 사실을 인정할 수 있습니다. 이미 배포 된 캐싱 요소의 실제 동작을 이해해야합니다. 많은 일반적인 캐싱 방법 (예 : HTTP ETag)에는 일관성을 유지하기 위해 여전히 네트워크 왕복이 필요하며, 네트워크 대기 시간이 비싼 경우이를 피할 수 있습니다. 다른 캐싱 접근법.
병렬화 : 논리적으로 엄격하게 순차적으로 발행 될 필요가없는 순차적 트랜잭션을 찾고 시스템을 재 작업하여 병렬로 발행하십시오. 엔드 투 엔드 요청에 ~ 2 초의 고유 한 네트워크 지연이 있었지만 단일 트랜잭션에는 문제가 없었지만 사용자가 클라이언트 응용 프로그램에 대한 제어권을 다시 얻기 전에 6 번의 2 회 왕복 여행이 필요한 경우를 처리했습니다. 그것은 엄청난 좌절의 원인이되었습니다. 이러한 트랜잭션이 실제로 독립적이라는 사실을 발견하면 트랜잭션을 병렬로 실행할 수있어 최종 사용자 지연이 단일 왕복 비용에 매우 가깝습니다.
결합 : 순차적 요청을 순차적 으로 실행 해야하는 경우이를보다 포괄적 인 단일 요청으로 결합 할 수있는 기회를 찾으십시오. 일반적인 예로는 새 엔터티 만들기와 해당 엔터티를 다른 기존 엔터티와 관련시키는 요청이 있습니다.
압축 : 텍스트 형식을 이진 형식으로 바꾸거나 실제 압축 기술을 사용하여 페이로드 압축을 활용할 수있는 기회를 찾으십시오. 많은 최신 (즉, 10 년 이내) 기술 스택이이를 거의 투명하게 지원하므로 구성해야합니다. 압축의 영향으로 대역폭이 아닌 근본적으로 대기 시간이 문제인 것으로 보 였는데, 트랜잭션이 단일 패킷 내에 들어가거나 패킷 손실을 피할 수 있고 그에 따라 크기가 크지 않다는 사실을 알게 된 경우가 종종 있습니다. 성능에 영향을 미칩니다.
반복 : 처음으로 돌아가서 개선 된 부분으로 작업을 동일한 위치와 시간에 다시 측정하고 결과를 기록하고보고하십시오. 모든 최적화와 마찬가지로 일부 문제는 현재 지배적 인 다른 문제를 노출하여 해결되었을 수 있습니다.
위의 단계에서는 애플리케이션 관련 최적화 프로세스에 중점을 두지 만 물론 기본 네트워크 자체가 애플리케이션을 지원할 수있는 가장 효율적인 방식으로 구성되어 있는지 확인해야합니다. 비즈니스에서 네트워킹 전문가를 참여시키고 용량 개선, QoS, 네트워크 압축 또는 기타 기술을 적용하여 문제를 해결할 수 있는지 확인하십시오. 일반적으로 응용 프로그램의 요구 사항을 이해하지 못하므로 분석 단계 후 응용 프로그램과 논의하고 응용 프로그램에서 발생하는 비용에 대해 비즈니스 사례를 작성하는 것이 중요합니다. . 잘못된 네트워크 구성으로 인해 애플리케이션 데이터가 오버랜드 링크가 아닌 저속 위성 링크를 통해 전송되는 경우가 발생했습니다. 네트워킹 전문가가 "잘 알려지지 않은"TCP 포트를 사용했기 때문입니다. 이와 같은 문제를 수정하면 소프트웨어 코드 나 구성 변경이 전혀 필요없이 성능에 큰 영향을 줄 수 있습니다.
마지막 몇 %는 CPU와 응용 프로그램에 따라 다릅니다 ....
목록은 계속됩니다 .... 그러나 이런 종류의 것들이 실제로 최후의 수단입니다 ...
x86을 빌드하고 적절한 성능 프로파일 링을 위해 코드에 대해 Valgrind / Cachegrind를 실행 하십시오. 또는 Texas Instruments의 CCStudio 에는 달콤한 프로파일 러가 있습니다. 그러면 당신은 어디에 집중해야하는지 알게 될 것입니다 ...
이전 답변만큼 심층적이거나 복잡하지는 않지만 다음과 같습니다. (초급 / 중급 수준이 높음)
말할 수 없습니다. 코드의 모양에 따라 다릅니다. 코드가 이미 존재한다고 가정하면 간단히 코드를보고 최적화하는 방법을 알아낼 수 있습니다.
더 나은 캐시 위치, 루프 언 롤링, 긴 종속성 체인을 제거하여 더 나은 명령 수준 병렬 처리를 얻으십시오. 가능하면 분기 위로 조건부 이동을 선호하십시오. 가능하면 SIMD 지침을 활용하십시오.
코드가 수행하는 작업을 이해하고 실행중인 하드웨어를 이해하십시오. 그런 다음 코드 성능을 향상시키기 위해 수행해야 할 작업을 결정하는 것이 상당히 간단 해집니다. 그것이 제가 생각할 수있는 유일한 진정한 조언입니다.
음, 그리고 "SO에 코드를 보여주고 특정 코드에 대한 최적화 조언을 요청하십시오".
더 나은 하드웨어가 옵션이라면 분명히 그쪽으로 가십시오. 그렇지 않으면
내가 사용하는 빠르고 더러운 최적화 기술은 다음과 같습니다. 나는 이것이 '첫 번째 패스'최적화라고 생각합니다.
시간이 어디에서 소비 되는지 알아보십시오 파일 IO입니까? CPU 시간입니까? 네트워크입니까? 데이터베이스입니까? 병목 현상이 아닌 경우 IO를 최적화하는 것은 쓸모가 없습니다.
환경 파악 일반적으로 최적화 할 위치를 아는 것은 개발 환경에 따라 다릅니다. 예를 들어 VB6에서는 참조로 전달하는 것이 값으로 전달하는 것보다 느리지 만 C 및 C ++에서는 참조로 전달하는 것이 훨씬 빠릅니다. C에서는 리턴 코드가 실패를 표시하면 무언가를 시도하고 다른 것을 수행하는 것이 합리적이지만 Dot Net에서는 예외를 포착하는 것이 시도하기 전에 유효한 조건을 확인하는 것보다 훨씬 느립니다.
인덱스 자주 쿼리되는 데이터베이스 필드에 인덱스를 만듭니다. 거의 항상 공간을 속도로 교환 할 수 있습니다.
조회 방지 루프 내부에서 최적화하기 위해 조회를 수행하지 않아도됩니다. 루프 외부의 오프셋 및 / 또는 색인을 찾아 내부 데이터를 재사용하십시오.
IO 최소화 특히 네트워크 연결을 통해 읽거나 쓰는 횟수를 줄이는 방식으로 설계하려고합니다.
추상화 감소 코드가 수행 해야하는 추상화 계층이 많을수록 느려집니다. 임계 루프 내에서 추상화를 줄입니다 (예 : 추가 코드를 피하는 하위 수준의 방법 공개)
사용자 인터페이스가있는 프로젝트의 스레드 생성, 느린 작업을 수행하기 위해 새 스레드를 생성하면 응용 프로그램의 응답 성 이 향상되지만 응답하지 않습니다.
전처리 일반적으로 공간을 빠르게 교환 할 수 있습니다. 계산이나 기타 강력한 작업이있는 경우 중요 루프에 들어가기 전에 일부 정보를 미리 계산할 수 있는지 확인하십시오.
이 답변은 다른 모든 답변에 포함되지 않았으므로 추가했습니다.
이것은 적어도 C / C ++에 적용됩니다. 이미 변환이 없다고 생각 하더라도 성능이 필요한 기능, 특히 루프 내 변환에 대한 감시를 수행하는 함수에 대해 컴파일러 경고를 추가하는 것이 좋습니다.
GCC spesific : 코드 주위에 자세한 pragma를 추가하여이를 테스트 할 수 있습니다.
#ifdef __GNUC__
# pragma GCC diagnostic push
# pragma GCC diagnostic error "-Wsign-conversion"
# pragma GCC diagnostic error "-Wdouble-promotion"
# pragma GCC diagnostic error "-Wsign-compare"
# pragma GCC diagnostic error "-Wconversion"
#endif
/* your code */
#ifdef __GNUC__
# pragma GCC diagnostic pop
#endif
이와 같은 경고로 인해 발생하는 전환을 줄임으로써 몇 퍼센트의 속도를 높일 수있는 사례를 보았습니다.
어떤 경우에는 우발적 인 변환을 방지하기 위해 엄격한 경고가 포함 된 헤더가 있지만, 의도적 인 의도적 인 변환에 많은 캐스트를 추가하여 코드를 최소한으로 혼란스럽게 만들 수 있기 때문에 트레이드 오프입니다 이익.
OS 및 프레임 워크를 조정하십시오.
과도하게 들릴 수도 있지만 다음과 같이 생각하십시오. 운영 체제 및 프레임 워크는 많은 작업을 수행하도록 설계되었습니다. 응용 프로그램은 매우 구체적인 작업 만 수행합니다. OS가 애플리케이션에 필요한 것을 정확하게 수행하고 프레임 워크 (php, .net, java)의 작동 방식을 애플리케이션이 이해하도록 할 수 있다면 하드웨어를 훨씬 더 잘 활용할 수 있습니다.
예를 들어, Facebook 은 Linux에서 일부 커널 레벨을 변경하고 memcached의 작동 방식을 변경했습니다 (예 : memcached 프록시를 작성하고 tcp 대신 udp를 사용함 ).
이에 대한 또 다른 예는 Window2008입니다. Win2K8에는 X 응용 프로그램 (예 : 웹 응용 프로그램, 서버 응용 프로그램)을 실행하는 데 필요한 기본 OS 만 설치할 수있는 버전이 있습니다. 이는 운영 체제가 프로세스를 실행하는 데 드는 오버 헤드를 크게 줄이고 성능을 향상시킵니다.
물론 첫 단계로 더 많은 하드웨어를 투입해야합니다.