4 ms·

It seems like this would eliminate the need to read a file from disk and fork a new process, both of which take time. If you're just removing a single file, th

It seems like this would eliminate the need to read a file from disk and fork a new process, both of which take time. If you're just removing a single file, this is probably negligible, but if you have a script iterating over 10k files, i.e., this speed-up may be more welcome.

viraptor 8y ago
> if you have a script iterating over 10k files That's probably a good sign you should advance from shell. If the script is trivial, it's going to be trivial in python / ruby / go / crystal / ... as well. If it's not trivial, that's another reason to move.
- adrianN 8y ago
  I agree that as scripts get more complex, you should migrate from bash. But the number of files a script touches says almost nothing about its complexity.
  - viraptor 8y ago
    Wasn't saying otherwise. One reason is complexity. Another is performance.
pwg 8y ago
True, but if you are iterating over 10k files and removing them, then a find|xargs pipe with xargs feeding rm the maximum number of parameters the kernel allows per fork will likely be faster than a bash interpreter loop, even with a bash builtin rm.
- e12e 8y ago
  You think find|xargs would be faster than (gnu) find -delete?
  - pwg 8y ago
    No, my comment was "will likely be faster than a bash interpreter loop". The key phrase is "bash interpreter loop". I was not comparing find|xargs to find -delete.