xargs -n1 -P4
Would be at most one arg from the arg list run with 4 jobs. http://stackoverflow.com/questions/28357997/running-programs...
In addition, I often use it to search for sequences by running grep in parallel. For example
$ parallel 'grep {1} -f haystack.txt' :::: many_needles.txt
Where {1} is a single line in many_needles.txt
$ fgrep -f many_needles.txt haystack.txtI admit I try to use -f all the time but your post suddenly made me realise I'd never actually measured the effect. :/
Edit: yes sorry I meant -F
There are two possible reasons why one might want to explicitly use fgrep/`grep -F`: 1) to avoid needing to escape a string that otherwise contains special regex characters and 2) because it permits the search tool to avoid the regexp engine entirely.
(1) is always a valid reason and is actually quite useful because escaping regexes can be a bother. But whether (2) is valid or not depends on whether your search tool is smart enough to recognize a simple literal search and automatically avoid the regex engine. Another layer to this is, of course, whether the regex engine itself is smart enough to handle this case for you automatically. Whether these optimizations are actually applied or not is difficult for a casual user to know. I don't actually know of any tool that doesn't optimize the simplest case (when no special regex features are required and it's just a simple literal search), so it seems to me that one should never use fgrep/`grep -F` for performance reasons alone.
However, if you use the `-f` flag, then you've asked the tool to do multiple string search. Perhaps in this case, the search tool doesn't try as hard to do simple literal optimizations. Indeed, I can actually witness evidence in favor of this guess. The first command takes 15s and the second command takes 10s:
LC_ALL=C grep -c -f queries /tmp/OpenSubtitles2016.raw.en
LC_ALL=C grep -c -F -f queries /tmp/OpenSubtitles2016.raw.en
$ cat queries
Sherlock Holmes
John Watson
Professor Moriarty
Irene Adler
Interestingly, performing a similar test using BSD grep shows no differences in the execution time, which suggests BSD grep isn't doing anything smart even when it knows it has only literals (and I say this because BSD grep is outrageously slow).
As a small plug, ripgrep is four times faster than GNU grep on this test and has no difference whether you pass -F or not.
(This is only scratching the surface of literal optimizations that a search tool can do. For example, a good search tool will search for `foo` when matching the regex `\w+foo\d+` before ever entering the regex engine itself.)
It may seem to be a trivial difference, but then you can search multiple haystacks at once fairly easily, and this approach scales to hundreds of millions of needles at once. The code for it isn't very difficult either, heck you can just use an in memory SQLite dB to get a searchable, temporary, index and rely on using some of the most tested software in history.
Basically using unique attributes of the data you then divide and conquer on those attributes (e.g. for Radix you make buckets based on the digits).
(Russ Cox's excellent writeup is here: https://swtch.com/~rsc/regexp/regexp4.html)
For my taste GNU parallel gets recommended a bit too quickly e.g. on Stackoverflow when the standard tools would do just fine. Your linked SO question is a prime example of that, xargs specific question yet there's a response that dismisses it entirely and suggests parallel when xargs can easily do the task at hand.
One of the two is part of a standard package that all Linux systems, and many non-Linux systems, have installed. The other is a special-purpose tool.
Your bet is irrelevant in the face of widely implemented standards. POSIX will outlive GNU coreutils. I'd bet your system also probably has a package manager that makes it easy to mark parallel as a dependency of your software.
>many non-Linux systems
Linux is pretty much the only system that typically ships GNU coreutils. The only one that comes to mind is Hurd.
For exactly this reason, GNU Parallel has the option --minversion.
So in your script you put:
parallel --minversion 20140722 || exit
if the rest of your script depends on functionality only present from version 20140722.
If the parallel in the $PATH is not GNU Parallel it will fail (and thus exit). If it _is_ GNU Parallel it will fail if the version is < 20140722 and succeed otherwise.
find -print0 | xargs -0 -n1 echo
echo -n "file '#1'\0file '#2'\0" | xargs -0 -n1 -I{} echo "the file is \"{}\", ok?"