전략적 벤치마크 설계와 데이터 필터링을 통한 Linter 성능 81% 개선

"How I Cut My Go Markdown Linter's Benchmark by 81%"

Kazu2026년 5월 26일12분intermediate

AI 요약

Context

AST나 Parse Tree 없이 단순 String Slice 기반으로 동작하는 Go Markdown Linter 구조 설계. 모든 Rule이 개별적으로 실행되며, 특히 코드 블록 식별을 위해 전체 문서를 매번 스캔하는 GetCodeBlockLineRanges 유틸리티의 중복 호출로 인한 성능 저하 발생.

Technical Solution

Violation-free 데이터셋을 활용한 전용 벤치마크 함수 설계로 에러 보고 비용을 제외한 순수 스캐닝 비용 측정
전역 범위의 코드 블록 Range를 사전 계산하여 Linear Search하는 방식에서 인라인 Fence Tracking 방식으로 전환하여 시간 복잡도 최적화
문자열 처리 전 첫 번째 Non-space Byte를 검사하는 Prefilter를 도입하여 불필요한 Rule 실행을 원천 차단
20개의 개별 PR 단위로 벤치마크 결과(benchstat)를 검증하여 각 최적화 기법의 기여도를 정밀하게 추적
CI 환경 내 벤치마크 수치 기반의 의사결정 체계를 구축하여 성능 회귀 방지 및 측정 노이즈 제거

실천 포인트

1. 성능 측정 시 에러 발생 케이스를 제외한 'Happy Path' 전용 벤치마크셋을 별도로 구성했는가?

2. 반복적인 전체 스캔(Full Scan) 대신 상태 기반의 인라인 처리(Inline Tracking)로 전환 가능한 지점이 있는가?

3. 무거운 로직 진입 전, 첫 바이트 검사와 같은 가벼운 Prefilter를 통해 처리 대상을 빠르게 필터링하고 있는가?

4. 성능 개선 사항을 하나의 큰 PR이 아닌, 측정 가능한 최소 단위의 PR로 나누어 검증하고 있는가?

태그

#Performance Optimization #Go #Linter #Benchmark #Time Complexity

원문 읽기