find 명령을 벤치마킹하는 방법이 있습니까(찾기와 비교)?

독서수락된 답변수상한찾기 대 찾기: 서로의 사용법, 장점 및 단점이는 locate이 앱의 가장 큰 장점이 속도라는 것을 의미하며 저는 이 앱을 사용함으로써 얻을 수 있는 이점이 있는지 확인하기 위해 몇 가지 테스트를 수행하고 싶었습니다.

find첫 번째 단계는 유사한 서비스를 제공할 때 도구의 속도를 추정하는 것이었습니다 locate(따라서 추가 항목은 없고 파일 이름만 검색함).

나는 보고 놀랐다

time find / 2>/dev/null >/dev/null

(사용자 권한에 따라) 모든 파일을 반복한다고 가정합니다.

real    0m1.231s
user    0m0.353s
sys 0m0.867s

꽤 빠른 결과.

내 질문은 적용된 명령이 실제로 속도를 벤치마크하는 방법인지 여부입니다 find.

제가 대답하고 싶은 질문 중 하나는 파일 시스템, 즉 운영 체제(Linux 커널)에 결과에 영향을 미칠 수 있는 일종의 버퍼가 있습니까?입니다.

내 결과는 캐시를 제거하면 echo 3 > /proc/sys/vm/drop_caches속도가 크게 향상된다는 것입니다 find.

$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
$ time (find / 2>/dev/null >/dev/null)
real    0m24.290s
user    0m1.143s
sys 0m8.230s

그러나 내 Linux 시스템에서는 후속 사용이 약 1초로 find돌아갑니다 .mlocate

요약하자면, 나는 알고 싶습니다find 명령을 벤치마킹하는 방법(찾는 것과 비교)

업데이트/비고

이 질문은 또 다른 비교에 의해 촉발되었으며 측정/벤치마크 속도에 대해 질문하고 있지만 locate라이브 OS/파일 시스템(예 :)에서 수집된 데이터가 데이터베이스(예: ). 내 OS 커널은 캐시 동작이 꽤 좋기 때문에 or 를 통한 검색 실행 시간은 여전히 ​​꽤 비슷합니다 .findfindfindlocatefindlocate

따라서 문제는 운영 체제(파일 시스템) 캐시를 제거하는 것이 find콜드 부팅을 완료하는 데 걸리는 "실제" 시간을 시뮬레이션하기에 충분한지 여부와 이러한 속도 향상 캐시가 지속된다고 가정하는 것이 얼마나 현실적인지(비슷한 내용)로 귀결됩니다. updatedb locate모든 후속 find호출 에 대해 데이터베이스 파일로 ).