In that sense it's unfortunate that I'm running 5.0. I have checked the EXPLAIN for the query and the possible keys are postid, userid, threadid. The join uses userid and threadid, so it just depends on which has fewer results, but most likely it will end up using userid, which is okay for MySQL 5.0 people, but others will have to look at their query speeds to see if this is actually an improvement.

Those that ask for screenshots are probably people who are not fluent in vbulletin.com talk.

I strongly suggest anyone to not use this hack!vBulletin staff though of every performance possibility and if there would be one,I think they would use it.

Although I would have to agree with you that Jelsoft did an excellent job with performance in vBulletin (compare MediaWiki), I must also say that at least running MySQL 5.0.27, having developed a number of hacks using the Pre-Process hooks...

I have tested the page on my server (your server will definitely have different results) with the hooks enabled and disabled, only running this particular hack.

Processing times at average peak performance for each has revealed the following:

disabled ~ 0.002 + enabled

With the hooks disabled, times have been known to dip (extremely rarely) to the following results:

disabled + 0.001 ~ enabled

The difference as you can see is minimal in terms of time efficiency. In terms of server load:

disabled ~ 0.50 + enabled

and there is not the rare occasion where disabled dips lower than enabled.