[Trigunflame]

You are correct vissa in the search aspect, although I have not done realtime benchmarks im almost certain that a fulltext search in mysql would be faster than an ereg or array manipulation THEN search inside the result of a flatfile.

But that is not what this script is doing, you will still be using mysql to search, the post will still be stored in mysql. This script will only make a change to the part of vbulletin that actually shows the post in which case will be drawn from a flatfile WHICH will be faster and less CPU intensive than a query of result rows from MySQL, I should also mention using less Memory.

In your regardst to threads, i doubt that is wh at UBB is referring to. They probably just coined that name in reference to "threads" as in topics. "Real" "Threads" are kernel dependent things. Depends on if your BSD/*Nix/etc build supports "Threading" which extended support can be compiled from within MySQL if you build it yourself.

To support optimized MultiThreading you have to build a kernel with modified File Handles, a new Glibc and latest and greatest LinuxThreads module then build your MySQL using other-libc its a pretty complicated process but lets you optimize the range of MySQL of about 400% or more. In tests ive done as well as various books, its shown that doing a MultiThread modfication can take a fully optimized MySQL from being able to handle several hundred active connections to well over 4000, limited only by your file handle count.

Only problem is, a lot of people dont know that trick and instead rely on getting multiple DB servers, when they can solve their problem with a semi-complex recompile.

Back to the subject, flatfile will always be faster for fetching results, and since these are done in read mode, they can support multiple file reads at once, there is no locking when done with reading.