A cleaned up fork of ngrep for OpenBSD
git clone git://
Log | Files | Refs | README | LICENSE

commit 058d22925eeb2687733b35f26da6691264a0e708
parent 28077a19eb535d2e702bf68e2a49de6bf21b701a
Author: Jordan Ritter <>
Date:   Sun, 25 Feb 2001 14:42:46 +0000

Added some discussion of the differences between GNU regex and PCRE.

AREADME.pcre | 30++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+), 0 deletions(-)

diff --git a/README.pcre b/README.pcre @@ -0,0 +1,30 @@ +A note on PCRE vs GNU regex: + + I ran several tests comparing GNU regex to the PCRE library + using 10 million loop iterations: optimized vs. non-optimized, + match vs. non-match. The conclusion I came to was that an + unoptimized PCRE program is almost double the match and + non-match times of the GNU regex library yields, and when using + optimization a PCRE program would perform almost the same in the + non-match case, but again almost twice that of the match case. + + The test subject was "how now brown cow", and the pattern we + were searching for in the match case was "now brown", and in the + non-match case "not brown". Obviously, the speed of matches is + directly related to the actual regex itself, and a + well-formulated regex certainly performs more efficiently than a + simple substring match. However, this test is indicative of how + most people use ngrep, so the test results are still important. + + Granted, on the single-match level the time difference is + absolutely unnoticeable (it took 10 million loop iterations to + compute it), so this may not mean anything to you. Likewise, + the stripped binary sizes are also within 10k of each other on + the test compile box. + + If absolute speed is not the issue, then compile against PCRE + since it has better licensing. If you're after the fastest you + can get (for you netops and netadmins out there, you know who + you are), then compile against GNU regex. The speed really + helps when piping those 500MB pcap dump files through ngrep over + and over.