수치를 믿기 전에 벤치마크를 재현하세요.

공개 fixture에는 commit, 환경, 샘플 수, 측정 범위, 경계가 포함됩니다. 팀의 저장소에도 같은 기준을 적용하세요.

검증된 벤치마크

랜딩 페이지용으로 만든 수치가 아니라 유지 관리되는 fixture에서 측정했습니다.

아래 수치는 재현 가능한 환경, fixture, commit, 범위를 포함한 Criterion 결과입니다.

측정일
2026-08-08
Version
1.0.0 · 0fb2efc
방법
Criterion 0.5.1 · radar-bench/parse_and_query
TypeScript 파싱 · 직접10.566 ms

10.546–10.595 ms

TypeScript 파싱 · 캐시 미스10.753 ms

10.703–10.819 ms

TypeScript 파싱 · 캐시 사용71.038 µs

70.938–71.168 µs

유지 관리되는 TypeScript 쿼리 10개 실행36.096 ms

35.953–36.254 ms

카탈로그 컴파일 및 TypeScript 쿼리 10개 실행62.155 ms

61.881–62.479 ms

유지 관리되는 모든 AST 규칙25.266 ms

25.185–25.368 ms

스캔 요약 · 빈 캐시13.538 ms

13.494–13.586 ms

스캔 요약 · 영구 캐시8.404 ms

8.356–8.469 ms

FixtureSynthetic TypeScript · 5,002 lines · 130,884 bytes
환경Apple M2 · 8 cores · 16 GB · macOS 27.0 · arm64
방법최적화된 벤치마크 프로필 · 3초 워밍업 · 100개 측정 샘플
벤치마크 소스
crates/radar-bench/benches/parse_and_query.rs
소스 SHA-256
7c40e89a4d63314e0fb95f50226621b6c806950817d94bfdc5b5cc0827917e58
fixture SHA-256
226cab8c9fc6c1af4ba30e550e1a7d469b6e9741822487ef1d64b02febb0bb22
범위 경계

이 측정은 유지 관리되는 파서, 규칙, 스캔 세션 fixture를 다룹니다. 모든 저장소, 머신, 규칙 세트, 네트워크에 대한 종단간 속도 보장이 아닙니다.

재현하려면 측정된 커밋의 소스 체크아웃에 접근할 수 있어야 합니다.

속도를 비교하기 전에 benchmark 해석하기

Code Radar benchmark는 문서화된 환경과 commit에서 지정 fixture를 측정합니다. cold, warm, parser, rule과 scan-session 값은 재현 가능한 실행을 설명하며 모든 코드베이스에 대한 보장이 아닙니다.

  • 신뢰할 측정에는 fixture와 source hash, 하드웨어와 소프트웨어 환경, 표본 수, 측정 범위, 명령, warm-up 동작과 제외 항목이 포함됩니다.
  • 고정 fixture만으로 저장소 성능을 예측할 수 없습니다. 파일 구성, 캐시, manifest, 활성 규칙, 저장장치, runner 부하와 출력 형식이 결과를 바꿉니다.
  • 게시된 fixture를 재현하고 대표 저장소에 같은 측정 규율을 적용해 속도와 발견 유용성을 함께 비교한 뒤 팀 정책을 변경하세요.

속도를 비교하기 전에 benchmark 해석하기 검증 방법

실제 산출물과 명확한 한계를 사용하세요. 방문자가 확인하고 관련 단계를 재현하며 무엇을 증명하지 않는지 이해할 수 있을 때 주장이 유용합니다.

결정 영역확인할 내용
근거신뢰할 측정에는 fixture와 source hash, 하드웨어와 소프트웨어 환경, 표본 수, 측정 범위, 명령, warm-up 동작과 제외 항목이 포함됩니다.
한계고정 fixture만으로 저장소 성능을 예측할 수 없습니다. 파일 구성, 캐시, manifest, 활성 규칙, 저장장치, runner 부하와 출력 형식이 결과를 바꿉니다.
다음 단계게시된 fixture를 재현하고 대표 저장소에 같은 측정 규율을 적용해 속도와 발견 유용성을 함께 비교한 뒤 팀 정책을 변경하세요.

속도를 비교하기 전에 benchmark 해석하기 관련 질문

이 답변은 페이지의 약속을 관찰 가능한 근거, 명확한 한계와 워크플로를 진전시키는 다음 행동에 연결합니다.

속도를 비교하기 전에 benchmark 해석하기에서 어떤 근거를 확인해야 하나요?

다음 근거를 확인하세요. 신뢰할 측정에는 fixture와 source hash, 하드웨어와 소프트웨어 환경, 표본 수, 측정 범위, 명령, warm-up 동작과 제외 항목이 포함됩니다.

속도를 비교하기 전에 benchmark 해석하기이 증명하지 않는 것은 무엇인가요?

이 한계를 명확하게 유지하세요. 고정 fixture만으로 저장소 성능을 예측할 수 없습니다. 파일 구성, 캐시, manifest, 활성 규칙, 저장장치, runner 부하와 출력 형식이 결과를 바꿉니다.

속도를 비교하기 전에 benchmark 해석하기을 검토한 뒤 무엇을 해야 하나요?

결정에 맞는 다음 단계를 사용하세요. 게시된 fixture를 재현하고 대표 저장소에 같은 측정 규율을 적용해 속도와 발견 유용성을 함께 비교한 뒤 팀 정책을 변경하세요.

올바른 검증 또는 구현 경로로 이동하세요.

이 페이지들은 현재 결정을 실제 산출물, 설치 단계, 워크플로 담당 영역 또는 상업적 경계와 연결합니다.

자신의 코드에서 워크플로를 검증하세요.

한 번의 로컬 스캔으로 시작해 근거를 확인하고, 신호가 유용할 때만 보고서, 에이전트, CI로 확장하세요.

git checkout 0fb2efc
shasum -a 256 crates/radar-bench/benches/parse_and_query.rs crates/radar-bench/benches/fixtures/synthetic_large.ts
cargo bench -p radar-bench --bench parse_and_query