41–50 of 225 posts
Side question: why is speed important? Which tools use fd to gain required performance?
Earlier quoted context omitted.
I'm curious why you (or anyone) uses -exec? It's often painfully slower than piping through xargs and I find the syntax (the semicolon and braces and the required quoting/escaping) uncomfortable. I haven't used -exec in 20 years.
It's not even slower (and it's safe beyond the argv limit) if you use "+" instead of the semicolon. find -type f -exec sed -i s/foo/bar/ {} + This only invokes the command twice for 100k files (assuming we can pass in 64k arguments to sed)
With the obligatory sneaky Rust advertisement in the title, my bullshit detector rings all its bells. And once more it was right.
“Be civil. Don't say things you wouldn't say face-to-face. Don't be snarky. Comments should get more civil and substantive, not less, as a topic gets more divisive.”
Calling something bullshit is both unwarranted in this case and unfair to the person whose work you’re dismissing. They built something and gave it to you for free – if you’re not interested just move along.
Any plan to provide find compatibility for drop-in replacement? My find/locate usage patterns are not worth learning new sophisticated tool for 5sec speedup once a week, and I suspect that I’m not alone. This is the main problem of new tools — not repeating the old-familiar style makes it unattractive for non-aggressive users. Side question: why is speed important? Which tools use fd to gain required performance?
It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…
I've found that fzf has replaced all uses of find for me except in scripts. fzf has the benefits of being bound to a single key binding and showing me results as I type, rather than after the command runs.
It can't even search specifically for directories, as far as I can see, nevermind searching for files/dirs with certain permissions, ages, etc.
It's also uselesss for non-interactive uses such as scripting.
I like fzf, but it's really not anywhere close to a complete find replacement.
Earlier quoted context omitted.
Thank you for the feedback! Most of the credit for the speed goes to the amazing Rust modules 'ignore' and 'regex', which are also used by ripgrep ( https://github.com/BurntSushi/ripgrep ).
Did you do a benchmark with `--threads 1`? I suspect most of the speedup is coming from that as the the listing of the files is likely to be IO bound (or at least bound by calling into the kernel to read the directory listings). That has certainly been my experience in the past when experimenting with this sort of thing, that more threads makes a lot of difference.
I did. You are right, multi-threading does not give a linear speed up, but it makes fd about a factor of three faster on my machine (8 virtual cores). With `--threads 1`, fd is on-par with 'find -iname', but still faster than 'find -iregex'.
find -type d -empty -delete
find -type l -exec readlink -f {} +