Plan9 grep is competitive in my simple test, often faster.
It is also immune from the pathological data that will kill GNU grep - see http://swtch.com/~rsc/regexp/
and the BUGS section of your local GNU grep
#!/usr/local/plan9/bin/rc
fn 9grep { /usr/local/plan9/bin/grep '2010-[0-9][0-9]-23 02:01:57' /home/maht/lighttpd.error.log > /dev/null }
fn ggrep { /usr/bin/grep '2010-[0-9][0-9]-23 02:01:57' /home/maht/lighttpd.error.log > /dev/null }
fn mgrep { /usr/bin/grep -mmap '2010-[0-9][0-9]-23 02:01:57' /home/maht/lighttpd.error.log > /dev/null }
switch($1) {
case -9
9grep
case -g
ggrep
case -m
mgrep
case *
ls -l /home/maht/lighttpd.error.log
time /tmp/gtest -9
time /tmp/gtest -g
time /tmp/gtest -m
}
/tmp/gtest
-rw-r--r-- 1 www wheel 1113325534 Aug 23 18:51 /home/maht/lighttpd.error.log
23.67 real 3.88 user 3.74 sys
24.28 real 0.63 user 3.89 sys
23.09 real 0.56 user 3.87 sys
It looks like all three of your grep commands there are I/O-bound (where are you getting a machine with much less than a gig of RAM, but 50 megabytes per second of disk streaming? Is this an old server with a RAID?), but plan9 grep uses six times as many CPU cycles as the other greps.
I wouldn't call that "competitive", even if system-call overheads does knock that crippling slowdown down to less than a factor of two.
Also, what kind of kernel are you running there that would peg your CPU with a mere 300 megabytes per second of disk I/O? Is DMA disabled on your disk or something? Surely not, because there aren't any IDE PIO modes that are anywhere close to 50 megabytes per second.
Comments
Plan9 grep is competitive in my simple test, often faster. It is also immune from the pathological data that will kill GNU grep - see http://swtch.com/~rsc/regexp/ and the BUGS section of your local GNU grep
It looks like all three of your grep commands there are I/O-bound (where are you getting a machine with much less than a gig of RAM, but 50 megabytes per second of disk streaming? Is this an old server with a RAID?), but plan9 grep uses six times as many CPU cycles as the other greps.
I wouldn't call that "competitive", even if system-call overheads does knock that crippling slowdown down to less than a factor of two.
Also, what kind of kernel are you running there that would peg your CPU with a mere 300 megabytes per second of disk I/O? Is DMA disabled on your disk or something? Surely not, because there aren't any IDE PIO modes that are anywhere close to 50 megabytes per second.