Швидші альтернативи "знайти" та "знайти"?


22

Мені б хотілося використовувати "знайти" і знайти "для пошуку вихідних файлів у моєму проекті, але вони потребують тривалого часу. Чи існують більш швидкі альтернативи цим програмам, про які я не знаю, або способи прискорити продуктивність цих програм?


2
locateвін повинен бути досить швидким, враховуючи, що він використовує попередньо вбудований індекс (основний застереження полягає в тому, що його потрібно постійно оновлювати), при цьому findчитати списки каталогів.
afrazier

2
Який пошук ви використовуєте? mlocate швидше, ніж розміщувати довгий шлях (зауважте, який би пакет ви встановили, команда все-таки знайдеться, тому перевірте свого менеджера пакунків)
Павло,

@benhsu, коли я працюю find /usr/src -name fprintf.cна своєму робочому столі OpenBSD, він повертає розташування цих вихідних файлів менше ніж за 10 секунд. locate fprintf.c | grep '^/usr/src.*/fprintf.c$'повертається за секунду. Яке ваше визначення «довгий час для запуску» і як ви використовуєте findі locate?
Кусалаланда

@Paul, я використовую mlocate.
benhsu

@KAK, я хотів би використати висновок find / locate, щоб відкрити файл у emacs. я маю на увазі випадок використання, я хочу редагувати файл, вводя ім'я файлу (або який-небудь повторний вираз, що відповідає імені файлу) в emacs, і emacs використовуватиме find / locate, щоб відкрити список файлів, що відповідають йому, тому мені сподобається час відповіді досить швидко, щоб бути інтерактивним (менше 1 секунди). У мене є близько 3 мільйонів файлів у $ HOME, одна річ, яку я можу зробити, це зробити, щоб моя команда пошуку вирізала деякі файли.
benhsu

Відповіді:


16

Пошук вихідних файлів у проекті

Використовуйте більш просту команду

Як правило, джерело для проекту, ймовірно, знаходиться в одному місці, можливо, в декількох підкаталогах, вкладених не більше двох-трьох глибоких, так що ви можете використовувати (можливо) більш швидку команду, наприклад

(cd /path/to/project; ls *.c */*.c */*/*.c)

Скористайтеся метаданими проекту

У проекті С ти зазвичай маєш Makefile. В інших проектах у вас може бути щось подібне. Це може бути швидким способом отримання списку файлів (та їх розташування), написання сценарію, який використовує цю інформацію для пошуку файлів. У мене є сценарій "джерела", щоб я міг писати такі команди, як grep variable $(sources programname).

Швидкість пошуку

Шукайте менше місць, а не find / …використовуйте, find /path/to/project …де можливо. По можливості спростіть критерії відбору. Використовуйте трубопроводи, щоб відкласти деякі критерії відбору, якщо це більш ефективно.

Також ви можете обмежити глибину пошуку. Для мене це значно покращує швидкість «пошуку». Ви можете використовувати -maxdepth перемикач. Наприклад, '-maxdepth 5'

Швидкість пошуку

Переконайтеся, що він індексує місця, які вас цікавлять. Прочитайте сторінку людини та скористайтеся всіма варіантами, які відповідають вашим завданням.

   -U <dir>
          Create slocate database starting at path <dir>.

   -d <path>
          --database=<path> Specifies the path of databases to search  in.


   -l <level>
          Security  level.   0  turns  security checks off. This will make
          searchs faster.   1  turns  security  checks  on.  This  is  the
          default.

Видаліть необхідність пошуку

Можливо, ви шукаєте, бо ви забули, де щось є, або вам не сказали. У першому випадку пишіть замітки (документацію), в другому запитайте? Конвенції, стандарти та послідовність можуть багато допомогти.


10

Я використав частину відповіді RedGrittyBrick "пришвидшити пошук". Я створив менший db:

updatedb -o /home/benhsu/ben.db -U /home/benhsu/ -e "uninteresting/directory1 uninteresting/directory2"

потім вказав locateна це:locate -d /home/benhsu/ben.db


6

Я використовую тактику, щоб застосувати -maxdepthваріант із find:

find -maxdepth 1 -iname "*target*"

Повторіть із збільшенням глибини, поки не знайдете те, що шукаєте, або не втомитеся шукати. Перші кілька повторень, ймовірно, повернуться миттєво.

Це гарантує, що ви не витрачаєте час на перегляд глибини масивних під дерев, коли те, що ви шукаєте, швидше за все, знаходиться біля основи ієрархії.


Ось приклад сценарію для автоматизації цього процесу (Ctrl-C, коли ви бачите, що вам потрібно):

(
TARGET="*target*"
for i in $(seq 1 9) ; do
   echo "=== search depth: $i"
   find -mindepth $i -maxdepth $i -iname "$TARGET"
done
echo "=== search depth: 10+"
find -mindepth 10 -iname $TARGET
)

Зауважте, що притаманна надмірність (кожна пропуск повинна буде пройти папки, оброблені в попередніх пропусках) значною мірою буде оптимізована за допомогою кешування диска.

Чому findцей порядок пошуку не є вбудованою функцією? Можливо, тому, що це було б складно / неможливо здійснити, якби ви припустили, що надмірне обхід неприйнятний. Наявність -depthопції натякає на можливість, але на жаль ...


1
... таким чином виконуючи пошук "на першу ширину".
nobar

3

Ще одне просте рішення - використовувати новіші розширені гільзи. Для того, щоб:

  • bash: shopt -s globstar
  • ksh: встановити -o globstar
  • zsh: вже ввімкнено

Потім ви можете запускати такі команди у вихідному каталозі верхнього рівня:

# grep through all c files
grep printf **/*.c

# grep through all files
grep printf ** 2>/dev/null

Це має перевагу в тому, що він здійснює рекурсивний пошук у всіх підкаталогах і дуже швидкий.


3

Пошук срібла

Вам може бути корисно для швидкого пошуку вмісту величезної кількості файлів вихідного коду. Просто введіть ag <keyword>. Ось деякі з моїх результатів apt show silversearcher-ag:

Зазвичай я його використовую для:

-G --file-search-regex PATTERN Лише пошукові файли, назви яких відповідають PATTERN.

ag -G "css$" important

скріншот


1
в ripgrep в алгоритм нібито швидше , ніж silversearch, а також шанує .gitignoreфайли і пропуски .git, .svn, .hg.. папки.
ccpizza

@ccpizza Так? Silver Searcher також шанує .gitignoreі ігнорує приховані та бінарні файли за замовчуванням. Крім того, є більше учасників, більше зірок на Github (14700 проти 8300) і вже знаходиться на репості міських дистрибутивів. Будь ласка, надайте оновлене надійне порівняння сторонніх джерел. Тим не менш, ripgrepвиглядає чудово програмне забезпечення.
Пабло А

добре знати! Я жодним чином не пов'язаний з авторами (авторами) ripgrep, він просто відповідає моїй вимозі, тому я перестав шукати інші варіанти.
ccpizza

Шукач срібла .gitignoreтеж поважає . Це сказало, rgабсолютно дивовижно. По-перше, він має підтримку unicode. З мого досвіду rgпостійно, принаймні вдвічі швидше, ніж ag(YMMV), я думаю, це пов'язано з аналізатором регексу Руста, який, очевидно, ще не був готовий ще в роки ag. rgможе дати детермінований вихід (але не за замовчуванням), він може переглядати типи файлів у чорному списку, де agможе бути лише білий список, він може ігнорувати файли залежно від розміру (до побачення журнали) Я все ще використовую, agякщо мені потрібна відповідність міжрядкових рядків, що rgне може зробити.
The Pellmeister

2

Щоб знайти заміну, перегляньте fd . Він має простіший / інтуїтивніший інтерфейс, ніж оригінальна команда знаходження, і досить трохи швидший.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.