bbPress 0.8.2 introduced a new way of counting how many pages worth of information there were to display (how many pages worth of content, for example, there are to display in a user’s profile): MySQL’s FOUND_ROWS() function. It works very well for most bbPress sites.
It cripples large sites.
After upgrading the WordPress.org Support Forums to bbPress 0.8.2, the server very quickly melted into a belligerent heap of protesting electrons. Most of this was bbPress’ fault (though MySQL shares some of the blame).
FOUND_ROWS() seemed to be a “magic bullet” everywhere it was tested (including the bbPress.org forums). While that impression should have made me very wary, instead it led me to use SQL_CALC_FOUND_ROWS (the SELECT query companion to the FOUND_ROWS() function) in places that really didn’t need it.
Mea culpa.
Because of that misuse and because of MySQL’s poor SQL_CALC_FOUND_ROWS optimization, sites with hundreds of thousands of topics (such as the WordPress.org support forums) will actually be slower (much slower) using bbPress 0.8.2 than they were using bbPress 0.8.1. This despite the other database and query optimizations that went into bbPress 0.8.2.
A fix for this bug and fixes for those others we collect in the coming weeks will be packaged into a new release.
Until that time, if you have a large site (where large probably means “tens of thousands of topics or users”) that has noticeably slowed since upgrading to bbPress 0.8.2, there is a solution. Use the current code available from the bbPress svn repository’s 0.8 branch (available via svn or zip file).
Our Trac system lets you see the changes in that branch since the release of bbPress 0.8.2. In particular, this performance issue was fixed in changeset 867.
On most sites though, the slowdown will probably not be noticeable. Unless your site is getting bogged down by bbPress’ use of the database, there’s no need to change anything.
Ah ha! This explains some things.