A "not an answer" flag was raised against this answer. As you can see, it is not actually providing any new solutions, just comparing the ones already provided by other answers and showing which one is faster.

On the one hand, it is not an answer. It is not attempting to solve the issue. It is, however, providing useful information that can help users choose between the proposed methods.

Personally, I lean towards allowing that type of post. I have to, I have been guilty of posting such myself. In my own answer, I simply collected all posted solutions and compared them in terms of speed. That answer has received 9 upvotes to date and no downvotes, which (might) suggest that the community feels that such comparisons are useful.

So, how so we feel about comparative answers? Answers that provide no new method of solving the OP's issue but do provide useful information about the existing answers. Do we like them? Do we not? Should they be deleted? Or do we feel that they add useful information and can be tolerated?

6 Answers 6


I observe two things about that answer:

  1. Even if you've read every other answer, that one still offers additional information regarding the solutions proposed elsewhere.

  2. Even if every other answer was deleted, that answer would still allow a reader to solve the problem presented in the question.

Therefore, it isn't completely redundant and it can stand alone.

Quick update, since a few people seem to have assumed I was planning on deleting the other answers or something: observation #1 establishes that the answer isn't redundant, while observation #2 establishes that the answer is actually an answer - that while it builds on the work done by other answers, it does so without becoming dependent on them.

At worst, I see no harm in it, and for some readers it may offer significant benefits.

  • 1
    Well, is repeating the very same information hours after without pitting its own solution to the problem. All sites remove those kind of answers that just repeat someone else words, why we shouldn't?
    – Braiam
    Commented Feb 9, 2015 at 2:06
  • See edit, @Braiam.
    – Shog9
    Commented Feb 9, 2015 at 5:01
  • Sorry, but that just doesn't scale. If I was bastard enough, I would submit a comparative answer of all solutions in any question, just to prove the point that such answers shouldn't be accepted.
    – Braiam
    Commented Feb 9, 2015 at 14:43
  • 1
    @Braiam it's odd, my first thought at seeing your "if I was…" [should that be were?] is "please do."
    – derobert
    Commented Feb 9, 2015 at 16:18
  • @derobert maybe. D:
    – Braiam
    Commented Feb 9, 2015 at 17:03
  • 2
    If you're feeling froggy... @Braiam
    – Shog9
    Commented Feb 9, 2015 at 17:49

Does it answer the question? Clearly; in fact, it gives four solutions. That alone makes it an answer (i.e. not not-an-answer).

So, the question is, should it be downvoted?

Does it add value compared to the other solutions? Yes, it gives objective benchmarks. Those can be very helpful in figuring out which solution to use for in and similar situations.

If anything should be changed about this post, it's that it should give credit to the authors of the posts from which his solutions are taken.

  • Yep, I added a comment to that effect (we were apparently thinking the same thing). Also, I think credit is probably actually required by the CC license.
    – derobert
    Commented Feb 5, 2015 at 17:35
  • 1
    Eh; unless he's copying other answers verbatim the license doesn't come into play. Still a polite thing to do.
    – Shog9
    Commented Feb 6, 2015 at 2:07

I think that enhancements or clarifications to existing solutions are Ok, as long as long as the resulting post is itself an answer. Case in point, some years ago I added the following answer: “unpacking” a tuple to call a matching function pointer. This formally adds absolutely nothing new to the answer by Johanne, but it has 24 upvotes and no downvotes at this time of writing, so presumably people find it useful.

  • Through, you think you don't add anything new, you are actually giving a more succinct explanation to what's being done by the code, unlike Johannes which only gives OP the fish. And I don't think you are "comparing", but further expanding a single answer (since editing might not be adequate)
    – Braiam
    Commented Feb 9, 2015 at 2:09

Are answers comparing existing answers acceptable?

No. Those answers are essentially regurgitating someone else words. They do not give anything novel back (frankly, I don't trust any Joe Doe performance tests, not even mines), and just serve to clutter the answers further with the information already available somewhere else.

If someone considers that one solution is fastest/cheaper/awesome they can readily express them by upvotes and/or comments complementing the information on the answer.

I agree that the NAA flag wasn't exactly the flag it should be raised here, but a "other" -> "this answer doesn't add anything new and simply repeats the solutions of other answers", which I believe any moderator would acted by deleting the answer.

So, when comparing existing answers is a valid answer? When your very own solution is part of the comparison:

I recommend fooring the bar with X tool, since the times are 20, 23 and 40 percent faster than Joe, Marc, Jhon solutions.

Otherwise, you are just cluttering the answers. If you want to add your own comparison, just comment on the specifics answers you benchmarked (or whatever variable you were comparing).

  • If there is a new solution in the answer, that others have not provided yet, that should have focus (at the top of the answer e.g.) as that solves the OPs problem, and therefore might help others, who have found the post, directly. Such an answer should IMO always be acceptable, whatever other detail you provide (speed comparison or not). But I agree on the limited value of regurgitating (and disagree with the need to have backup answers copying data in advance as Shog9 point 2 seems to suggest).
    – Anthon
    Commented Feb 9, 2015 at 2:55
  • And maybe I should just copy your comment on Shog9's answer there in case you decide to delete it ;-)
    – Anthon
    Commented Feb 9, 2015 at 3:00
  • See my edit, @Anthon - I wasn't actually suggesting that other answers would be deleted.
    – Shog9
    Commented Feb 9, 2015 at 5:01

The original question is already a duplicate and now we have more duplicated information, that is, in addition, not really critical of the solutions used (e.g. using the default grep instead of grep -F which can be used as there are no patterns involved (muru's answer).

IMO it is preferable to have this answer in a separate Q&A pair, whereby the title of that question should be adapted to what the answer answers, i.e. includes information about the speed comparison. That way someone might actually hit upon the answer, now googling for text processing speed comparison unix.stackexchange.com doesn't seem to show things (but that might be my googling deficiency). A link to the original question and answers with appropriate credits would of course be necessary.


I really like comparisons of different tools. When we decide which tool should be used for the given job then time needed for particular operation is one of the most important thing (the others are availability, portability, etc). So yes, for me it is perfectly acceptable answer, and at least once I gave similar comparison: https://unix.stackexchange.com/a/156602/80886.

Now, with that being said I have to admit that discussed benchmark looks fishy to me because I can hardly believe that 3 consecutive grep are 6x faster than single grep, and 10x faster than single awk. Really???

I made a fast xcheck:

# creating the file by repeating next 'cat' until abc.txt=196MB
$ cat /usr/src/linux/Documentation/**/*.txt >> abc.txt


  • single awk:

    $ time bash -c "awk '/a/ && /b/ && /c/' abc.txt >> /dev/null"
    7.75s user 0.23s system 99% cpu 7.984 total
  • triple grep:

    $ time bash -c "grep a abc.txt | grep b | grep c >> /dev/null"
    5.65s user 1.41s system 188% cpu 3.745 total
  • single grep

    $  time bash -c "grep -e 'a.*b.*c' -e 'a.*c.*b' -e 'b.*a.*c' -e 'b.*c.*a' -e 'c.*a.*b' -e 'c.*b.*a' abc.txt >> /dev/null"
    2.43s user 0.13s system 99% cpu 2.565 total
  • single perl:

    $ time bash -c "perl -ne 'print if /a/ && /b/ && /c/' abc.txt >> /dev/null"
    11.95s user 0.21s system 99% cpu 12.174 total

I'm not saying that something is incorrect in that answer, but above results make more sense to me:

  • grep as a dedicated tool is fastest because it is designed and optimized to do only one job, and do it fast.
  • single grep is faster than 3, because no time is wasted for forking
  • perl is slowest as it is the largest program

Test done on weak netbook with atom processor, so only relative times make sense.

  • Your tests really should be an answer to the main question, they don't belong on meta. That said, the tests will very much depend on your input. I created a 100MB file of random data with 100 characters per line and ran each of the solutions 20 times to get an average. The single grep was indeed faster (0.10s), followed by perl (0.23) and awk (0.26) and the piped grep was last at 0.5. Perl is very good at text processing and the && mean that lines will be skipped as soon as they don't match one of the three. Presumably, grep will need to process the whole line multiple times.
    – terdon Mod
    Commented Feb 6, 2015 at 15:21
  • This is precisely why we shouldn't allow this. Nobody is really qualified to do accurate benchmarking nor has the time to actually do it.
    – Braiam
    Commented Feb 9, 2015 at 2:07
  • no time is wasted for forking - a fork isn't always a waste, though - especially when chained in a single pipeline. You have to consider that calling grep three times means more than just having to call it - it also means you get 3 greps processing the same stream concurrently. Whether or not that is useful depends mostly on whether or not there is enough data to justify it - you only have to fork the three times at the beginning after all. And - especially when the lines get very long - resolving all of those optional * gets pretty expensive.
    – mikeserv
    Commented Feb 10, 2015 at 9:42
  • Actually, I was just thinking about this again (dunno if you care to) but I wonder if you ran those tests on a more typical system if the results wouldn't come out differently. I wouldn't think the atom processor could offer much in the way of concurrency, but on my six-core the two ways are about even at around [12]00 lines of average length, but as soon as the lines get long or the line count approaches the 1000s the 3-grep chain begins to pull ahead at an exponential rate.
    – mikeserv
    Commented Feb 13, 2015 at 3:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .