The majority of people do know how to drive though (in the western part of
the world where the majority has a car anyway)...and as sandos noted; all
the regex searchs you provided in your tests were archivable with substring
search as well...

it was just to be able to compare speed between substring search and regex.

Being in posix.2 means, among other things, that it's not covered by the
standard c library...it also means that it's not available on windows, and
although you might think that linux is the answer to everything, I doubt
that your client comes even close to the >1000000 downloads that dc++ had
in it's second latest version (and that being from sf only, not counting
the countless mirrors and freeware cd's its being distributed
through)...hence, the major dc platform does not support regexes without
library support...

IMHO, it is a bad explanation. The only reason your client is downloaded so many time is probably because it is better than the standard nmdc client and because both are available on windoz. It has nothing to do with the capabilities of the system. If we should have waited for a good network protocol from windoz, we still would run netbeui, not TCP/IP. If a feature must be added, a possible missing function is a bad reason, just add it.

It is. Even some of your simple searches took ~0.1s, imagine what a more
complex one would do that actually uses the enhanced expressiveness of
regexes (start by introducing a few | and you'll see...), and if it takes
0.1s it means that the highes search throughput will be 10searches/s with
100% cpu, which is not very impressive, not in my eyes anyway...

but not everyone share as many files as the test share file. Moreover, currently, the problem is not the CPU speed, it is the bandwidth (especially upstream). If performing 40 searches per second use all your upload bandwidth then I think we will just have something like ed2k (good to find something, awful to obtain it).

Eric