fd 10.0.0 и bfs 3.2

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

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

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

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

Едрить, у этих наркоманов -h и --help это не синонимы, а разные вещи.

Всё-таки растоманы повёрнутые.

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

То ли дело curl --help all, да? :)

В curl общепринятую логику работы этого ключа не сломали. curl -h all и curl --help all означают одно и то же.

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

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

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

По мне, так вывод у fd -h всяко лучше, чем у man --usage.

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

man man для мужиков!

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

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

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

Новость о сразу двух конкурентах =)

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

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

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

80 Tavian Barnes 5.4%

Чот мне в макоси и файнда с грепом хватает :)

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

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

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

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

bfs ещё быстрее

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

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

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

Summary
  fd -u . /media ran
    2.53 ± 0.94 times faster than bfs /media
   29.05 ± 9.01 times faster than find /media

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

наверное у тебя нет цели понтоваться на ютубе)

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

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

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

А bfs откуда?

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

Summary
  bfs /lib/ ran
    1.30 ± 0.05 times faster than fd . /lib/

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

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

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

А bfs откуда?

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

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

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

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

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

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

Опять забыл про -u. :)

Summary
  fd -u . /lib/ ran
    1.27 ± 0.09 times faster than bfs /lib/

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

Корень:

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

Хомяк:

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~~-помойка~~ с данными:

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-у.

bfs сливает даже find-у

Так на моём свежаке – тоже. :)

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

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

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

rg

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

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

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

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

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

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

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

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

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

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

rg

ugrep и ugrep-indexer 1.0.0! :)

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

most?

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

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

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

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

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

 ~ $ stty size
37 140
 ~ $ for i in $(seq 0 160); do echo -n "*"; done | less -S~# 2

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

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

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

du -h и du --help

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

226146

Сразу видно что Debian у человека…

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

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

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

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

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

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

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

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

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