eric writes:
>[...]
> Finally, I have run a bigger test (3 lines of code :) ). I have
> written a small PERL program which does the same search:
> ==============
> while (<>) {
>    print if /.*microsoft.*/;
>    }
> ==============
> The run time (including perl loading and perl is big :) ) is
> between 0.07 and 0.09s. This clearly means perl like expression is
> usable.

From what I've heard (or at least as stated by the PHP manual), the

PCRE engine than the glibc regex engine. I guess the extra just
_might_ come from the fact that you're running it in an interpreted
language (and yes, I know Perl has a compiler, but, no, it doesn't
compile to native code). Nonetheless, having an interpreted langauge
do the search in less than 0.1 seconds is a really good indication
that it's more than well feasible. As you can also see from my own
test, speed really doesn't seem to be a problem, even for extremely
large file lists.

What I can't understand is why Carl-Adam's C# code was so enormously
much slower (why are you mumbling 77 times faster when in fact it is
closer to a thousand times?), but I guess it is to be expected from a
M$ invention...

Carl-Adam, had you pre-heated the buffer cache before running your
test. If not, could you please do so and rerun it? I just can't
imagine even .net would be _that_ slow.

> I think that instead of removing features to a powerful search
> model, there is a more simple solution. Why a client could not just
> discard some search queries when it is overloaded.

Precisely what I have been thinking all the time. I don't know why I
didn't say it, though... =)

Fredrik