LINUX.ORG.RU

fd 10.0.0 и bfs 3.2

 , , , ,

fd 10.0.0 и bfs 3.2

0

2

Состоялся выпуск 10.0.0 консольной утилиты поиска файлов fd, написанной на языке Rust и распространяемой по лицензиям MIT и Apache 2.0.

Изменения:

  • к directory добавлен псевдоним dir при использовании ключа -t/--type;
  • добавлена поддержка формата даты @%s в фильтрах времени, аналогично GNU date (секунд с эпохи Unix для --older/--newer);
  • теперь автоматически не игнорируется директория .git при использовании ключа --hidden с включенным игнорированием VCS;
  • исправлено определение переменной окружения NO_COLOR при использовании опции --list-details;
  • исправлена ошибка вывода скрытых файлов, если путь поиска был .;
  • сборки aarch64 теперь используют 64-килобайтные страницы (при использвании jemalloc);
  • минимальная поддерживаемая версия Rust теперь 1.77.2 (для исправления CVE-2024-24576, только для Windows).

А 2 мая состоялся выпуск 3.2 аналогичной утилиты bfs, но написанной на языке C.
Изменения:

  • добавлено действие -limit N, которое завершается сразу после получения N результатов;
  • реализована функция -context (из GNU find) для поиска контекстов SELinux;
  • реализована функция -printf %Z для вывода контекстов SELinux;
  • переписана система сборки;
  • улучшена поддержка платформ:
    • реализация -acl для Solaris/Illumos;
    • реализация -xattr для DragonFly BSD.

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: Dimez (всего исправлений: 2)

Ответ на: комментарий от no-such-file

а для обработки.

Понимаете в чем соль, обработка начинается с xarg а он как раз может в параллель, но растаманам это не понять.

mx__ ★★★★★
()
Ответ на: комментарий от numas13

правильнее fd -u
This is an alias for ‘–no-ignore –hidden’.

Видимо, не часто используется, так как в fd -h этой опции нет, только в fd --help. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Да. Обычно -I или -H не нужны, т.к. эти файлы/директории искать не нужно, но для более или менее одинакового сравнения с find эти файлы лучше учитывать. К тому же это может очень сильно ускорить fd, т.к. не надо делать лишнюю работу по поиску и разбору файлов игнорирования/etc.

numas13
()
Ответ на: удаленный комментарий

Понимаю, ты старался, расписывал. Но кто тебя об этом просил? Я сам не пользуюсь ничем из этого и обычно троллю на лорчике :)

По сабжу - не нравится, не ешь, как говорится. Бинарник аналогичной утилиты bfs написан на С и весит 234 КБ, если что.

З.Ы. Мне с головой хватает fzf

Gonzo ★★★★★
()
Последнее исправление: Gonzo (всего исправлений: 1)
Ответ на: комментарий от splinter

bfs:

linux-vdso.so.1
libacl.so.1 => /usr/lib/libacl.so.1
libcap.so.2 => /usr/lib/libcap.so.2
liburing.so.2 => /usr/lib/liburing.so.2
libonig.so.5 => /usr/lib/libonig.so.5
libc.so.6 => /usr/lib/libc.so.6
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2
Gonzo ★★★★★
()
Ответ на: комментарий от sena

Иногда из 100500 файлов надо обработать десяток

Иногда надо, иногда не надо. Суть в том что это относительное преимущество, и как я уже сказал оно во многих ситуациях уничтожается долгим временем обработки того, что найдено. Я могу согласится, что в каких-то специальных сценариях скорость может быть решающим фактором.

Опять же эта скорость не из астрала берётся. Как оно ведёт себя на нагруженной системе, где нет свободных процов?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от beastie

А директорий мало. Срани с /usr или /var хохмы ради.

А почему такие полумеры? Надо сравнить ещё для случая когда много поисков запущенно параллельно. Т.е. например 1000 find/fd параллельно. Неплохо было бы ещё что-нибудь тяжёлое компилять на фоне. Тогда будет видно, кто тут для продакшена, а кто на локалхосте цветные картинки смотреть.

no-such-file ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Да, бывает. :)
И автор bfs иногда участвует в fd:

80 Tavian Barnes 5.4%

dataman ★★★★★
() автор топика

Годно, нужно. Давно пользуюсь fd — значительно быстрее, чем find работает, что иногда бывает очень приятно. Про bfs слышу впервые, надо будет заценить.

То, что там бинарь на 4 МБ, это, конечно, не здорово. Но то, что оно во много раз быстрее find’а, перекрывает для меня этот недостаток. Ну и удобный синтаксис бонусом.

P.S. попробовал bfs. Не, fd всё ещё быстрее:

CommandMean [ms]Min [ms]Max [ms]Relative
fd -u . /usr41.3 ± 2.236.146.01.00
bfs /usr61.8 ± 2.560.075.31.50 ± 0.10
find /usr296.1 ± 4.7293.1308.97.18 ± 0.39

Это ещё малая разница. Мне лень было более реальный юзкейс проверять — долго же, особенно учитывая, что это ж много попыток с hyperfine. Но так и быть, сейчас оно отпыхтит, скину по /media вместо /usr. Минут через 20, блин…

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 3)
Ответ на: комментарий от dataman

bfs ещё быстрее

Теоретически, может быть. На практике fd обходит мой $HOME в 3 раза быстрее.

intelfx ★★★★★
()
Ответ на: комментарий от dataman

На моём железе fd всё еще ощутимо быстрее. Версии последние, из арчереп.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Наконец отпыхтело.

Summary
  fd -u . /media ran
    2.53 ± 0.94 times faster than bfs /media
   29.05 ± 9.01 times faster than find /media
CommandMean [s]Min [s]Max [s]Relative
fd -u . /media4.726 ± 1.4553.2977.4761.00
bfs /media11.969 ± 2.5138.53214.8592.53 ± 0.94
find /media137.276 ± 5.328126.135144.14229.05 ± 9.01

Вот, собственно, поэтому я в своё время был очень рад обнаружить fd. Одно дело, когда оно 5 секунд тупит — тоже время, но это не ломает workflow, так сказать, просто ощущается как небольшое подлагивание, вместо моментального результата. И совсем другое, когда сидеть и пялить в экран приходится больше двух минут. Да даже если бы и одну минуту — всё равно разница колоссальная для меня.

CrX ★★★★★
()
Ответ на: комментарий от CrX

P.S. попробовал bfs. Не, fd всё ещё быстрее

У меня в тестах обратная ситуация.

wandrien ★★
()
Ответ на: комментарий от CrX

попробовал bfs. Не, fd всё ещё быстрее

А bfs откуда?

В общем, bfs по умолчанию компилируется дебажный. Нужно сконфигурировать релиз: ./configure --enable-release.

Summary
  bfs /lib/ ran
    1.30 ± 0.05 times faster than fd . /lib/
dataman ★★★★★
() автор топика
Ответ на: комментарий от beastie

Но. Всё равно я find не брошу, потому что он хороший. :)

В скриптах, которые я не только для себя пишу, тоже find юзаю, потому что он везде есть.

Но в интерактиве всё же fd экономит кучу времени

CrX ★★★★★
()
Ответ на: комментарий от dataman

А bfs откуда?

Я дальше написал — всё из арчевских реп. Версии последние.

В общем, bfs по умолчанию компилируется дебажный. Нужно сконфигурировать релиз: ./configure –enable-release

Там ./configure RELEASE=y — не то?

CrX ★★★★★
()
Ответ на: комментарий от wandrien

Были б понты, может и понтовался бы :) А так чот стар я стал, девушки все равно не полюбят :)

gns ★★★★★
()
Ответ на: комментарий от CrX

ам ./configure RELEASE=y — не то?

Не пробовал, там самописный скрипт.

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Ваш свежак какой-то протухший.

Корень:

CommandMean [ms]Min [ms]Max [ms]Relative
find /mnt/rootfs604.4 ± 5.2597.3614.95.27 ± 0.22
devel/ext/fd/target/release/fd -u . /mnt/rootfs114.8 ± 4.7106.4126.51.00
devel/ext/bfs/bin/bfs /mnt/rootfs209.9 ± 15.2186.5242.81.83 ± 0.15
Benchmark 1: find /mnt/rootfs
  Time (mean ± σ):     604.4 ms ±   5.2 ms    [User: 171.6 ms, System: 431.0 ms]
  Range (min … max):   597.3 ms … 614.9 ms    10 runs
 
Benchmark 2: devel/ext/fd/target/release/fd -u . /mnt/rootfs
  Time (mean ± σ):     114.8 ms ±   4.7 ms    [User: 1294.0 ms, System: 918.6 ms]
  Range (min … max):   106.4 ms … 126.5 ms    25 runs
 
Benchmark 3: devel/ext/bfs/bin/bfs /mnt/rootfs
  Time (mean ± σ):     209.9 ms ±  15.2 ms    [User: 211.7 ms, System: 680.4 ms]
  Range (min … max):   186.5 ms … 242.8 ms    16 runs
 
Summary
  devel/ext/fd/target/release/fd -u . /mnt/rootfs ran
    1.83 ± 0.15 times faster than devel/ext/bfs/bin/bfs /mnt/rootfs
    5.27 ± 0.22 times faster than find /mnt/rootfs

Хомяк:

CommandMean [s]Min [s]Max [s]Relative
find /home/intelfx2.339 ± 0.0152.3112.3556.37 ± 0.23
devel/ext/fd/target/release/fd -u . /home/intelfx0.367 ± 0.0130.3530.3971.00
devel/ext/bfs/bin/bfs /home/intelfx0.772 ± 0.0310.7240.8132.10 ± 0.11
Benchmark 1: find /home/intelfx
  Time (mean ± σ):      2.339 s ±  0.015 s    [User: 0.586 s, System: 1.745 s]
  Range (min … max):    2.311 s …  2.355 s    10 runs
 
Benchmark 2: devel/ext/fd/target/release/fd -u . /home/intelfx
  Time (mean ± σ):     367.0 ms ±  13.1 ms    [User: 4320.2 ms, System: 4306.2 ms]
  Range (min … max):   352.8 ms … 396.7 ms    10 runs
 
Benchmark 3: devel/ext/bfs/bin/bfs /home/intelfx
  Time (mean ± σ):     772.0 ms ±  31.1 ms    [User: 763.5 ms, System: 2938.2 ms]
  Range (min … max):   723.7 ms … 813.2 ms    10 runs
 
Summary
  devel/ext/fd/target/release/fd -u . /home/intelfx ran
    2.10 ± 0.11 times faster than devel/ext/bfs/bin/bfs /home/intelfx
    6.37 ± 0.23 times faster than find /home/intelfx

SSD~~-помойка~~ с данными:

CommandMean [s]Min [s]Max [s]Relative
find /mnt/ssd11.886 ± 0.05411.82911.9846.79 ± 0.17
devel/ext/fd/target/release/fd -u . /mnt/ssd1.750 ± 0.0431.6951.8251.00
devel/ext/bfs/bin/bfs /mnt/ssd12.604 ± 0.57711.99313.5977.20 ± 0.37
Benchmark 1: find /mnt/ssd
  Time (mean ± σ):     11.886 s ±  0.054 s    [User: 2.870 s, System: 8.976 s]
  Range (min … max):   11.829 s … 11.984 s    10 runs
   
Benchmark 2: devel/ext/fd/target/release/fd -u . /mnt/ssd
  Time (mean ± σ):      1.750 s ±  0.043 s    [User: 18.936 s, System: 17.819 s]
  Range (min … max):    1.695 s …  1.825 s    10 runs
    
Benchmark 3: devel/ext/bfs/bin/bfs /mnt/ssd
  Time (mean ± σ):     12.604 s ±  0.577 s    [User: 4.986 s, System: 17.209 s]
  Range (min … max):   11.993 s … 13.597 s    10 runs
 
Summary
  devel/ext/fd/target/release/fd -u . /mnt/ssd ran
    6.79 ± 0.17 times faster than find /mnt/ssd
    7.20 ± 0.37 times faster than devel/ext/bfs/bin/bfs /mnt/ssd

Забавно, что на самом большом датасете bfs сливает даже find-у.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от dataman

Это и странно. У тебя тесткейс миллип5.1ческий, всё должно быть наоборот.

intelfx ★★★★★
()

Потрясающая утилита. Пользуюсь только ей! rg и fd - предвестники новой эры.

Теперь бы найти замену less…

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

rg

Долго выбирал между ним и ag, остановился на последнем — на моих юзкейсах он таки чаще быстрее. Хотя и не на любых.

Теперь бы найти замену less…

Он-то чем не устраивает?

CrX ★★★★★
()
Ответ на: комментарий от dataman

В times оно не очень интересно. В секундах надо. А то может ты 10 милисекунд и 12 милисекунд сравниваешь, и там вся разница в «прогреве» запуска самой программы, а не в её непосредственно работе.

У меня одно ажно вот так: fd 10.0.0 и bfs 3.2 (комментарий)

5 секунд против 11 и против двух с лишним минут у тормозного find.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Теперь бы найти замену less…

Он-то чем не устраивает?

Ну вот из последних проблем: Как использовать less с бесконечным источником?

А так - в целом много чем не устраивает. Довольно топорная программка по сути. К примеру поиск в ней использует не пойми какие регэкспы. Пишу ‘/’, ‘\s’ он мне подсвечивает буквы s - ну и что это такое? Мне нужны нормальные регэкспы. В целом поиск там адски медленный на фоне того же rg, изучение какого-нибудь 10-гигабайтового лога практически невозможно. Нельзя включить режим raw и отключить переводы строк (да и вообще странная идея - иметь отдельный режим только для включения подсветки, она должна просто из коробки работать, без всяких режимов). Нет режима hex или чего-то такого, чтобы спокойно смотреть бинарные файлы. Не показывает номера строк сбоку. Зачем-то экраном хлопает, когда выходишь, а если это отключить, то ещё что-то там ломалось, уже не помню. Да много претензий на самом деле, так сходу и не вспомнишь всё.

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 3)
Ответ на: комментарий от CrX

Он-то чем не устраивает?

Как и во многих подобных случаях, пользователь зачастую не знает, что его не устраивает, пока не попробует вариант лучше :)

Эргономика — она такая. I know it when I see it.

intelfx ★★★★★
()
Ответ на: комментарий от vbr

Теперь бы найти замену less…

Тоже искал, но не нашел другой пейджер, который умеет прокручивать горизонтально. Например если нужно прокрутить вывод, который превышает ширину консольного окна. Например:

 ~ $ stty size
37 140
 ~ $ for i in $(seq 0 160); do echo -n "*"; done | less -S~# 2
dmitry237 ★★★★
()
Ответ на: комментарий от vbr

Нет режима hex или чего-то такого, чтобы спокойно смотреть бинарные файлы.

Вот это, на мой взгляд, уже лишнее — для этого есть отдельный софт.

С остальным, пожалуй, соглашусь. Хотя мне всегда хватало.

CrX ★★★★★
()
Ответ на: комментарий от fumanchez

В этих случаях -h — сложившееся исключение из закономерности.

Придумывать собственное исключение от балды — плохая идея.

wandrien ★★
()
Ответ на: комментарий от sanyodesu

ну, параллельное выполнение комнад в find сделать относительно просто, самое простое - это + или xarg -P

а вот c «параллельный обход каталогов» - не так всё просто.

ибо может упереться всё в локальный носитель и в проц.

mumpster ★★★★★
()
Ответ на: комментарий от vbr

то что тебе нужен less для просмотра огромного файла, да ещё и продолжающего ехать дальше - говорит о том, что ты домашнее задание не сделал. у тя в итоге должно быть резюме из max 1-2 экранов нужного, остальное - отфильтровано.

блин, да я даже в венде стараюсь так делать хотя там намного это сложнее если не прибегать к PS. а тут 100500 вариантов, но выбран самый странный.

mumpster ★★★★★
()
Ответ на: комментарий от wandrien

Завезти стабильный ABI (и, как следствие, динамическую компоновку) можно всегда. Да, это сложная проблема, и жаль, что её оставили на потом (вместо решения since day 1, как в том же Swift-е), но фундаментально она решаемая. Я уверен, ты это понимаешь, но всё равно выбираешь тупое улюлюканье.

Жаль, я думал, ты адекватнее.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от wandrien

Сделай патчи, пришли авторам

Очевидно, не у всех есть желание копаться в сишной кодовой базе образца 90-х.

Это же самое и к find применимо, кстати

Ну вот, опять начинаешь указывать другим, как им жить и на что тратить своё время.

Зачем же ты тогда пилишь своё недо-DE? Сделай патчи в GNOME, пришли авторам :-)

intelfx ★★★★★
()
Ответ на: комментарий от wandrien

В 2.8М бинарного кода может уместиться встраиваемая операционная система

Да. Но она будет не на Rust’е!

BydymTydym
()
Ответ на: комментарий от vbr

Теперь бы найти замену less…

Братишка, попробуй more. Реально, более другое…

BydymTydym
()

Посмотрел я на свое вчерашнее сообщение fd 10.0.0 и bfs 3.2 (комментарий)

И думаю что тут не так, глянул на него, ну точно.

Я немного лишнего отрезал от квоты (то что в скобках) и народ не понимает про что я написал.

минимальная поддерживаемая версия Rust теперь 1.77.2 (для исправления CVE-2024-24576, только для Windows).

Иными словами если бы не это исправление для винды то минимальная версия уже была бы ниже.

mx__ ★★★★★
()
Ответ на: комментарий от intelfx

О каком стабильном ABI идёт речь, когда программа и так линкуется с glibc?

Если программа, которая просто ходит по файловой системе и исполняет несложный DSL и машину состояний регэкспов, компилируется в несколько мегабайт бинарного кода, то проблема не в ABI, а в том, как организованы библиотеки.

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.