Blazing Rust
측정된 성능을 향상시키되 동작은 유지합니다. 대표적인 입력에 대해 반복 가능한 향상을 가져오는 가장 간단한 변경을 선택하세요.
편집 전 측정
- 워크로드, 대상 메트릭, 정확성 제약 조건을 식별하세요. 핫패스와 호출자를 읽으세요. 프로젝트의 툴체인, 최소 지원 Rust 버전, 기능, 배포 대상을 존중하세요. 설명 요청은 측정 및 프로파일링을 승인할 뿐, 편집을 승인하지 않습니다.
- 일반적으로
release인 프로젝트의 최적화된 프로덕션 프로필로 기준을 캡처하세요. 입력, 정확한 명령어, 툴체인, 플래그, CPU, 스레드 수를 기록하세요. 현실적인 입력 크기와 분포를 사용하고, 작은 입력과 악의적인 입력도 포함하세요. - 성능을 제한하는 요소를 찾으세요. 적절하게 CPU 시간, 할당, I/O, 또는 락 대기를 프로파일링하세요. 비동기 중단의 경우, 런타임 인식 트레이싱으로 태스크 스케줄링과 큐 증가를 검사하세요. 기존 도구를 먼저 사용하세요; 프로파일링 섹션은 일반적인 도구와 릴리스 빌드에서 심볼을 유지하는 방법을 나열합니다. 프로파일링이 불가능하면 목표를 정한 측정을 사용하고 증거의 한계를 명시하세요.
- 가설을 세우고 하나의 측정 가능한 변경을 수행하세요. 집중된 정확성 테스트를 실행하고 동일한 벤치마크를 반복하세요. 사용자가 체감할 수 있는 개선을 주장하기 전에 전체 워크로드에서 결과를 검증하세요.
- 입증된 개선만 유지하세요. 실패한 편집만 되돌리고, 관련 없는 작업은 보존하세요. 목표가 달성되었거나 추가 변경에 증거가 부족할 때 중단하세요.
벤치마크의 신뢰성 확보
- 설정, 컴파일, 입력 생성, 프로세스 시작을 대상 메트릭에 속하지 않는 한 작업에서 분리하세요. 결과를 소비하세요. 마이크로벤치마크의 경우, 벤치마크 라이브러리의 최적화 장벽 또는 입력과 출력에
std::hint::black_box를 사용하세요. 이러한 장벽은 최선의 노력(best effort)이므로, 의심스러운 결과를 검사하세요. - 동등한 작업과 출력을 비교하세요. 툴체인, 프로필, 기능, 할당자, CPU 설정, 스레드 수를 테스트 대상 변수가 아닌 한 고정하세요. 정상 상태 측정 시 워밍업하세요. 관련이 있을 때 콜드 스타트를 별도로 측정하세요.
- 실행을 반복하고 샘플 수, 중앙값, 변동성을 보고하세요. 드리프트가 중요할 때 기준과 후보 실행을 번갈아 가며 수행하세요. 노이즈 내의 차이는 승리로 간주되지 않습니다.
- 메트릭을 작업에 맞추세요. 서비스의 경우 명시된 부하에서 p95/p99 지연 시간, 처리량, 오류, 리소스 사용량을 측정하세요. 지연 시간 감소가 작업 누락이나 큐 증가로 인한 것이 아닌지 확인하세요.
- 기존 벤치마크를 재사용하세요. 새 로직이 필요할 때 작은 회귀 케이스를 추가하세요. 작업 승인 없이 도구를 설치하거나, 의존성을 추가하거나, 빌드 설정을 변경하지 마세요. 측정을 임의로 만들지 마세요.
증거에 기반한 변경 선택
불필요한 작업과 알고리즘부터 시작하세요. 남은 병목이 요구할 때만 저수준 변경을 고려하세요. 측정된 병목에 대해 더 자세한 내용이 필요하면 기법 가이드의 해당 섹션을 읽으세요.
| 관찰된 비용 | 후보 변경 및 확인 사항 |
|---|---|
| 반복적인 스캔 또는 계산 | 알고리즘이나 컬렉션 선택 개선. 중복된 파싱, 정렬, 직렬화, 조회 제거. 캐싱이 도움이 된다면 캐시 무효화와 메모리 고려. |
| 할당 또는 복사 | &str과 슬라이스를 빌리고, 소유된 값을 이동시키고, 버퍼를 재사용하고, 신뢰할 수 있는 용량을 예약하세요. 할당된 값을 대체할 때 clone_from을 시도하세요. 중간 컬렉션을 피하세요. clone은 공유 핸들의 경우 저렴할 수 있으므로 비용을 측정하세요. |
| 컬렉션 조회 | 빌린 키와 반복 작업을 피하는 entry API를 사용하세요. 접근 패턴이 맞을 때 밀집 벡터나 정렬된 데이터를 비교하세요. 해셔를 변경할 때 신뢰할 수 없는 키에 대한 충돌 공격 저항성을 유지하세요. |
| 정렬 또는 제거 | 선택에는 select_nth_unstable, 동등 요소 순서가 중요하지 않으면 sort_unstable, 비싼 키에는 sort_by_cached_key를 사용하세요. 요소 순서가 중요하지 않을 때만 swap_remove를 사용하세요. |
| 캐시 미스 또는 큰 값 | 구조체 배열과 배열 구조체를 비교하세요. size_of, align_of, 캐시 미스를 확인하세요. 인라인 저장소는 복사를 증가시킬 수 있습니다. 드문 큰 열거형 페이로드에 대해 박싱을 고려하되, 할당과 간접 참조를 고려하세요. |
| 작은 핫 호출 또는 루프 | 일반적인 반복을 선호하세요. 슬라이스, 반복, 또는 범위 어설션으로 컴파일러가 범위 검사를 제거하도록 도우세요. 인라이닝이나 언롤링 전에 최적화된 어셈블리를 검사하세요. 빈 입력, 꼬리, 오버플로, 코드 크기를 테스트하세요. |
| 텍스트 검색 | 컴파일된 정규식을 재사용하고 필요한 매치 정보만 요청하세요. 인코딩 의미가 허용할 때 특수화된 바이트 검색과 비교하세요. 핫 루프 내에서 검색 상태를 재구축하지 마세요. |
| 벡터화 가능한 계산 | 명시적 SIMD 전에 자동 벡터화를 확인하세요. 생성된 코드를 검사하세요. 필요한 곳에서 대상별 명령어를 보호하고 스칼라 폴백을 유지하세요. 꼬리와 대표적인 CPU를 테스트하세요. 정렬, 범위, 수치 동작을 유지하세요. |
| 독립적인 CPU 작업 | 직렬 실행과 제한된 병렬 처리를 비교하세요. 스케줄링 비용, 경합, 대역폭, 스레드 수, 총 CPU 소비를 측정하세요. 오버헤드가 중요할 때만 태스크 크기를 조정하세요. 축소 의미를 유지하세요. |
| I/O 또는 비동기 중단 | 라인 버퍼를 재사용하고, 작은 I/O를 배치하고, 플러시 오류를 처리하세요. 지연 시간, 개행 처리, 내구성을 유지하세요. 차단되거나 무거운 CPU 작업을 비동기 워커에서 멀리 유지하세요. 동시성과 큐를 제한하세요. 순서, 역압력, 취소를 유지하세요. |
| 빌드 또는 코드 생성 한계 | 기존 설정을 얇은 LTO와 비교하세요. 결합하기 전에 두꺼운 LTO와 codegen-units = 1을 별도로 테스트하세요. 빌드 시간과 바이너리 크기를 포함하세요. 배포 하드웨어가 허용할 때만 CPU별 플래그를 사용하세요. |
정확성 유지
공개 API, 오류 처리, 유효성 검사, 순서, 직렬화, FFI 계약을 그대로 유지하세요. 정수 오버플로와 부동소수점 동작을 유지하세요. 열거형 표현이나 변형 순서는 레이아웃과 판별자를 변경할 수 있습니다; 둘 다 더 작거나 빠른 열거형을 보장하지 않습니다.
안전한 Rust와 기존 의존성을 선호하세요. 안전하지 않은 코드를 도입하려면 측정된 필요, 명시적인 안전 불변성, 집중된 테스트가 필요합니다. 지원되고 관련이 있는 경우 Miri 또는 sanitizer를 사용하세요. 벤치마크 속도를 위해 유효성 검사나 건전성을 희생하지 말고, 테스트 통과를 건전성의 증거로 취급하지 마세요.
결과 보고
병목, 변경, 유지/롤백 결정을 명시하세요. 재현 가능한 명령어, 변동성을 포함한 전후 결과, 관련 할당 또는 메모리 수치, 정확성 확인, 트레이드오프를 포함하세요. 멀티코어 벽시계 시간 이득과 싱글코어 효율성을 구분하세요. 측정되지 않은 주장과 확인되지 않은 플랫폼을 명명하세요.