Grep rekursif vs. find / -type f -exec grep {} \; Mana yang lebih efisien / lebih cepat?

Manakah yang lebih efisien untuk menemukan file mana di seluruh sistem file yang berisi string: grep rekursif atau temukan dengan grep dalam pernyataan exec? Saya menganggap menemukan akan lebih efisien karena Anda setidaknya dapat melakukan beberapa penyaringan jika Anda tahu ekstensi file atau regex yang cocok dengan nama file, tetapi ketika Anda hanya tahu -type fmana yang lebih baik? GNU grep 2.6.3; find (GNU findutils) 4.4.2

Contoh:

grep -r -i 'the brown dog' /

find / -type f -exec grep -i 'the brown dog' {} \;

Saya tidak yakin:

grep -r -i 'the brown dog' /*

benar-benar yang Anda maksudkan. Itu berarti grep secara rekursif di semua file dan dirs non-tersembunyi /(tapi masih mencari di dalam file dan dirs tersembunyi di dalamnya).

Anggap Anda maksud:

grep -r -i 'the brown dog' /

Beberapa hal yang perlu diperhatikan:

• Tidak semua grepimplementasi mendukung -r. Dan di antara mereka yang melakukannya, perilaku berbeda: beberapa mengikuti symlink ke direktori ketika melintasi pohon direktori (yang berarti Anda mungkin berakhir mencari beberapa kali dalam file yang sama atau bahkan berjalan dalam loop tak terbatas), beberapa tidak akan. Beberapa akan mencari di dalam file perangkat (dan itu akan membutuhkan beberapa waktu /dev/zeromisalnya) atau pipa atau file biner ..., beberapa tidak.
• Ini efisien karena grepmulai mencari ke dalam file begitu menemukan mereka. Tetapi sementara itu terlihat dalam sebuah file, itu tidak lagi mencari lebih banyak file untuk dicari (yang mungkin sama baiknya dalam kebanyakan kasus)

Anda:

find / -type f -exec grep -i 'the brown dog' {} \;

(menghapus -ryang tidak masuk akal di sini) sangat tidak efisien karena Anda menjalankan satu grepper file. ;seharusnya hanya digunakan untuk perintah yang hanya menerima satu argumen. Terlebih lagi di sini, karena grephanya terlihat dalam satu file, itu tidak akan mencetak nama file, sehingga Anda tidak akan tahu di mana pertandingannya.

Anda tidak mencari di dalam file perangkat, pipa, symlink ..., Anda tidak mengikuti symlink, tetapi Anda masih berpotensi mencari hal-hal seperti di dalamnya /proc/mem.

find / -type f -exec grep -i 'the brown dog' {} +

akan jauh lebih baik karena grepperintah sesedikit mungkin akan dijalankan. Anda akan mendapatkan nama file kecuali proses terakhir hanya memiliki satu file. Untuk itu lebih baik menggunakan:

find / -type f -exec grep -i 'the brown dog' /dev/null {} +

atau dengan GNU grep:

find / -type f -exec grep -Hi 'the brown dog' {} +

Perhatikan bahwa greptidak akan dimulai sampai findmenemukan cukup file untuk dikunyah, sehingga akan ada beberapa penundaan awal. Dan findtidak akan melanjutkan mencari lebih banyak file sampai sebelumnya greptelah kembali. Mengalokasikan dan melewati daftar file besar memiliki beberapa dampak (mungkin dapat diabaikan), jadi semuanya mungkin akan kurang efisien daripada grep -ryang tidak mengikuti symlink atau melihat ke dalam perangkat.

Dengan alat GNU:

find / -type f -print0 | xargs -r0 grep -Hi 'the brown dog'

Seperti di atas, beberapa grepcontoh mungkin akan dijalankan, tetapi findakan terus mencari lebih banyak file sementara grepdoa pertama mencari di dalam batch pertama. Itu mungkin atau mungkin tidak menguntungkan. Misalnya, dengan data yang disimpan pada hard drive rotasi, finddan grepmengakses data yang disimpan di lokasi yang berbeda pada disk akan memperlambat throughput disk dengan menyebabkan kepala disk bergerak terus-menerus. Dalam pengaturan RAID (di mana finddan grepdapat mengakses disk yang berbeda) atau pada SSD, yang mungkin membuat perbedaan positif.

Dalam pengaturan RAID, menjalankan beberapa pemanggilan serentak grep juga dapat meningkatkan banyak hal. Masih dengan alat GNU pada penyimpanan RAID1 dengan 3 disk,

find / -type f -print0 | xargs -r0 -P2 grep -Hi 'the brown dog'

dapat meningkatkan kinerja secara signifikan. Namun perlu dicatat bahwa yang kedua grephanya akan dimulai setelah file yang cukup telah ditemukan untuk mengisi grepperintah pertama . Anda dapat menambahkan -nopsi agar hal xargsitu terjadi lebih cepat (dan memberikan lebih sedikit file per greppermintaan).

Juga perhatikan bahwa jika Anda mengarahkan xargsoutput ke apa pun selain perangkat terminal, maka grepss akan mulai buffering output mereka yang berarti bahwa output dari mereka grepmungkin akan disisipkan secara tidak benar. Anda harus menggunakan stdbuf -oL(jika tersedia seperti pada GNU atau FreeBSD) pada mereka untuk mengatasinya (Anda mungkin masih memiliki masalah dengan garis yang sangat panjang (biasanya> 4KiB)) atau minta masing-masing menuliskan output mereka dalam file terpisah dan menggabungkannya semua pada akhirnya.

Di sini, string yang Anda cari sudah diperbaiki (bukan regexp) jadi menggunakan -Fopsi mungkin akan membuat perbedaan (tidak mungkin karena grepimplementasi tahu cara mengoptimalkannya).

Hal lain yang dapat membuat perbedaan besar adalah memperbaiki lokal ke C jika Anda berada di lokal multi-byte:

find / -type f -print0 | LC_ALL=C xargs -r0 -P2 grep -Hi 'the brown dog'

Untuk menghindari mencari ke dalam /proc, /sys..., gunakan -xdevdan tentukan sistem file yang ingin Anda cari:

LC_ALL=C find / /home -xdev -type f -exec grep -i 'the brown dog' /dev/null {} +

Atau pangkas jalur yang ingin Anda kecualikan secara eksplisit:

LC_ALL=C find / \( -path /dev -o -path /proc -o -path /sys \) -prune -o \
  -type f -exec grep -i 'the brown dog' /dev/null {} +

Jika *dalam greppanggilan tidak penting bagi Anda maka yang pertama harus lebih efisien karena hanya satu contoh dari grepdimulai, dan garpu tidak bebas. Dalam kebanyakan kasus akan lebih cepat bahkan dengan *tetapi dalam kasus tepi penyortiran bisa membalikkan itu.

Mungkin ada find- grepstruktur lain yang bekerja lebih baik terutama dengan banyak file kecil. Membaca entri dan inode file dalam jumlah besar sekaligus dapat memberikan peningkatan kinerja pada media yang berputar.

Tapi mari kita lihat statistik syscall:

Temukan

> strace -cf find . -type f -exec grep -i -r 'the brown dog' {} \;
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 97.86    0.883000        3619       244           wait4
  0.53    0.004809           1      9318      4658 open
  0.46    0.004165           1      6875           mmap
  0.28    0.002555           3       977       732 execve
  0.19    0.001677           2       980       735 stat
  0.15    0.001366           1      1966           mprotect
  0.09    0.000837           0      1820           read
  0.09    0.000784           0      5647           close
  0.07    0.000604           0      5215           fstat
  0.06    0.000537           1       493           munmap
  0.05    0.000465           2       244           clone
  0.04    0.000356           1       245       245 access
  0.03    0.000287           2       134           newfstatat
  0.03    0.000235           1       312           openat
  0.02    0.000193           0       743           brk
  0.01    0.000082           0       245           arch_prctl
  0.01    0.000050           0       134           getdents
  0.00    0.000045           0       245           futex
  0.00    0.000041           0       491           rt_sigaction
  0.00    0.000041           0       246           getrlimit
  0.00    0.000040           0       489       244 ioctl
  0.00    0.000038           0       591           fcntl
  0.00    0.000028           0       204       188 lseek
  0.00    0.000024           0       489           set_robust_list
  0.00    0.000013           0       245           rt_sigprocmask
  0.00    0.000012           0       245           set_tid_address
  0.00    0.000000           0         1           uname
  0.00    0.000000           0       245           fchdir
  0.00    0.000000           0         2         1 statfs
------ ----------- ----------- --------- --------- ----------------
100.00    0.902284                 39085      6803 total

grep saja

> strace -cf grep -r -i 'the brown dog' .
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 40.00    0.000304           2       134           getdents
 31.71    0.000241           0       533           read
 18.82    0.000143           0       319         6 openat
  4.08    0.000031           4         8           mprotect
  3.29    0.000025           0       199       193 lseek
  2.11    0.000016           0       401           close
  0.00    0.000000           0        38        19 open
  0.00    0.000000           0         6         3 stat
  0.00    0.000000           0       333           fstat
  0.00    0.000000           0        32           mmap
  0.00    0.000000           0         4           munmap
  0.00    0.000000           0         6           brk
  0.00    0.000000           0         2           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0       245       244 ioctl
  0.00    0.000000           0         1         1 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0       471           fcntl
  0.00    0.000000           0         1           getrlimit
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           futex
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0       132           newfstatat
  0.00    0.000000           0         1           set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00    0.000760                  2871       466 total

Jika Anda menggunakan SSD dan mencari waktu dapat diabaikan, Anda dapat menggunakan GNU parallel:

find /path -type f | parallel --gnu --workdir "$PWD" -j 8 '
    grep -i -r 'the brown dog' {} 
'

Ini akan menjalankan hingga 8 proses grep secara bersamaan berdasarkan apa yang findditemukan.

Ini akan meremukkan drive hard disk, tetapi SSD harus mengatasinya dengan cukup baik.

Satu hal lagi yang perlu dipertimbangkan dalam hal ini adalah sebagai berikut.

Apakah ada direktori yang grep harus secara rekursif melewati berisi lebih banyak file daripada pengaturan nofile sistem Anda ? (mis. jumlah pegangan file terbuka, standarnya adalah 1024 pada kebanyakan distro linux)

Jika demikian, maka mencari pasti cara untuk pergi karena versi grep tertentu akan membom dengan daftar Argument error terlalu lama ketika hits direktori dengan lebih banyak file daripada pengaturan menangani file terbuka maksimum.

Hanya 2 my saya.