# Such v1.3.5 — 기본 파일 검색 비교 벤치마크

## 비교 범위

- **실측한 운영체제 기본 도구**: Linux의 GNU `find`(파일명·확장자)와 `ripgrep`(파일 내용). `find`는 무인덱스 재귀 탐색, `ripgrep`은 현 시점의 파일을 직접 읽는 도구다. Linux GUI 파일 관리자/데스크톱 인덱스 검색의 실측값은 아니다.
- **Such 상주 엔진**: 승인된 Linux Private Runtime SO를 메모리에 로드한 뒤 C ABI로 검색(5회 예열+40회 반복)했다. GUI 상호작용·렌더링 지연은 측정하지 않았다.
- **Such CLI**: 검색마다 CLI와 Runtime을 새로 실행하는 실제 end-to-end 프로세스 벤치마크(1회 예열+5회 측정). 콘텐츠 CLI는 스니펫을 출력해 `rg -l`과 출력 범위가 다르다.
- **Windows 파일 탐색기 / Windows Search**는 이 Linux 컨테이너에서 실행할 수 없으므로 비교 수치를 제공하지 않는다. 특히 Windows의 인덱스 활성화 상태/대상 경로가 성능을 좌우한다. Windows 新 DLL의 멀티샤딩도 본 벤치마크에 포함하지 않는다.
- 데이터셋: 같은 합성 파일 10,000/100,000/500,000개, `cpp/txt/dwg/png/json` 분포, 50만 기준 약 2.0GiB. OS 페이지 캐시 가열, 동일 컨테이너(AMD EPYC 9V74 제한 CPU 5개, overlayfs), 인덱스는 이미 구축. 기본 도구는 2회 예열+7회 측정, 중앙값 사용. 50만 파일의 초기 Such 인덱싱은 이전 측정에서 59.72초, 초기 저장 공간 334.3MiB, 인덱싱 피크 RSS 1,202.8MiB였다.

## 1. 기본 검색 대비 상주 검색 엔진

| 파일 수 | 정확한 파일명 `find` | Such 상주 | 속도비(기본/Such) | 내용 `rg` | Such 상주 `/inside` | 속도비(기본/Such) |
|---:|---:|---:|---:|---:|---:|---:|
| 10,000 | 7.335ms | 0.0167ms | 439× | 19.354ms | 0.0346ms | 559× |
| 100,000 | 51.215ms | 0.0233ms | 2,198× | 112.652ms | 0.4067ms | 277× |
| 500,000 | 258.444ms | 0.0517ms | 4,999× | 533.429ms | 2.3306ms | 229× |

## 2. 50만 파일 — 쿼리 다양화

| 검색 | 기본 검색 | Such 상주 검색 | 기본/Such | 결과 개수 |
|---|---:|---:|---:|---:|
| 정확한 파일명 | 258.444ms | 0.0517ms | 4,999× | 1 |
| 결과 없는 파일명 | 243.137ms | 0.0364ms | 6,680× | 0 |
| 넓은 파일명 (engineering_plan) | 247.051ms | 60.6055ms | 4× | 99,999 |
| 확장자 DWG | 260.438ms | 50.4201ms | 5× | 100,000 |
| 텍스트 내용 | 533.429ms | 2.3306ms | 229× | 301 |

## 3. 실제 CLI 재실행 비용

| 파일 수 | GNU `find` (파일명) | SuchCLI 새 실행 (파일명) | `rg` 내용 검색 | SuchCLI 새 실행(`/inside`) |
|---:|---:|---:|---:|---:|
| 10,000 | 7.34ms | 28.69ms | 19.35ms | 29.19ms |
| 100,000 | 51.22ms | 300.62ms | 112.65ms | 372.29ms |
| 500,000 | 258.44ms | 1829.51ms | 533.43ms | 2561.02ms |

**결론:** 사전 구축한 인덱스를 계속 사용하는 Such의 엔진 검색은 반복 질의에 큰 우위가 있다. 하지만 SuchCLI는 매번 Runtime/인덱스를 로드하므로 현재 50만 파일에서 `find`·`rg`보다 느리다. 이는 상주 서비스를 추가하라는 의미가 아니라, CLI 초기 로딩 비용을 프로파일링해야 한다는 뜻이다. `find`·`rg`는 인덱스 생성 없이 즉시 최신 파일 시스템 내용을 볼 수 있고, Such는 인덱스를 먼저 생성·갱신해야 한다. 파일 갱신 인지 지연은 이번 테스트에서 측정하지 않았다.

## 보존/검증 사항

- 파일명/확장자/내용 결과 개수는 기존 GNU find/rg 교차 검증과 일치했다. 최신 Such C ABI 재측정에서 결과 건수 10k/100k/500k 및 fingerprint 일치 확인.
- Windows Search 인덱스 기반 검색 속도는 `find` 수치를 대입할 수 없으며 **UNVERIFIED**.
- 본 비교는 Linux Fix5 SO 전용. Windows v1.3.5 업데이트 DLL, Windows UI/IME, SearchIndexer.exe 설정은 실측하지 않았다.
- Private 소스, 사용자 파일, 원본 2GiB 코퍼스는 첨부하지 않는다.

## 부속 데이터

- `Such_1.3.5_vs_OS_Default_Search.csv`: 15개 케이스 요약.
- `Such_1.3.5_vs_OS_Default_Search_Repro.zip`: `find`/`rg`/Such CLI/상주 Runtime 재측정 스크립트와 CSV 출력.