Is this faster:

find /tmp -name core -type f | xargs /bin/rm -f

than doing this:

find /tmp -name core -type f -exec /bin/rm -f {} \;

So would using xargs increase overall speed?

(I got the example from the man page of xargs.)

  • 1
    Even faster is find /tmp -name core -type f -delete - no extra processes at all. – camh Nov 13 '11 at 12:41
  • 1
    Indeed, but it is requiring a Gnu specific extension. -exec rm -f {} + is the fastest still portable (POSIX) way. – jlliagre Nov 13 '11 at 13:53

As Mat already said, in the general case you should be aware of the fact that every byte can be in a filename, except the NUL character (as it delimits the end of the string) and the / (as it deleimits path elements). So your xargs example should be (on a GNU system)

find /tmp -name core -type f -print0 | xargs -0 /bin/rm -f

Equivalent is a -exec in the find, but with a + instead of the \;.

find /tmp -name core -type f -exec /bin/rm -f {} +

This version doesn't call /bin/rm for every file, but bundles the arguments, just as xargs does.

  • If you use time before each of the above commands, you can notice that xargs still beats exec with the +. – Hippo Nov 13 '11 at 14:41
  • 1
    It doesn't here and there is actually no technical reason for one to be significantly faster or slower than the other. The + solution is more elegant (IMHO) and works with all find implementations while the -print0 one is GNU specific and unnecessarily complex. – jlliagre Nov 15 '11 at 1:57

The first version can be faster than the second: xargs will pass multiple files at a time to rm, but find will call rm once per file.

So there can be less fork/exec calls with the first version.

(If there is a single match or none at all, the second version is likely to be faster though: no need to exec xargs itself.)

But I don't think that's a good criteria for choosing one or the other. In this specific case, you don't have to worry about strange filenames, but in general you should. The second version is safer, so you should, generally, use that.

  • 4
    Another point is that in the pipe version, the rm and find are working in parallel (at least if there is enough files to remove). I'd not be surprised that some times it helps, sometimes it hinders the performance. – AProgrammer Nov 13 '11 at 12:31
  • Interesting point, hadn't thought too much about that. For large number of files and dirs, total time is going to be dominated by directory read/update I/O in any case I believe, so most likely none of this actually matters :) – Mat Nov 13 '11 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.