> using strstr() instead of a whole PCRE engine This is probably faster on a lot of platforms with the common grep use-cases, yeah (i.e. very short literal str

> using strstr() instead of a whole PCRE engine This is probably faster on a lot of platforms with the common grep use-cases, yeah (i.e. very short literal strings). But as a common practice imo using the C library string functions in performance-sensitive code is tricky, because it can lead to some wildly variable performance between platforms, compared to directly using a portable-C implementation of a good algorithm. I was bitten by strstr() in particular in the past. I had a large slowdown when taking something pretty simple (filter/extraction code) that ran fine on Linux, and trying it on FreeBSD. It turns out that strstr() on FreeBSD implements the naive O(nm) algorithm: a loop around strncmp() that tries a match at each possible starting location [1]. That's fine for short search strings but increasingly bad for long ones. I had assumed that a typical strstr() would use Boyer-Moore or something of that sort past a threshold, but on many platforms it doesn't (GNU libc, at least in recent versions, does switch to Two-Way [2]). [1] http://svnweb.freebsd.org/base/head/lib/libc/string/strstr.c?revision=251069&view=markup#l44 http://svnweb.freebsd.org/base/head/lib/libc/string/strstr.c... [2] http://www-igm.univ-mlv.fr/~lecroq/string/node26.html http://www-igm.univ-mlv.fr/~lecroq/string/node26.html