1.0, unlike bbPress 0.9, loads each forum separately and then each forum’s metadata separately. This creates a huge number of queries – each forum makes 2 queries, ie. a dozen forums makes the front page use at least 24+6 queries. bbPress 0.9 would only use a single query to load them all (this was before metadata was added to forums). When it is eventually optimized, no matter how many forums you have it will use only two queries instead.

I already had the “$bb->load_options = true;” part, but I am setting up a forum with 17 forums as categories and 176 forums total. There are currently no topics, but here are the page load stats from the front page:

0.391 – 405 queries

For a single forum page:

0.148 – 359 queries

After patching bb-includes/functions.php I get this for the front page:

There is no actual page cache in bbPress. The cache setting you see is meant for the *object* cache which is meant to store things like the user data and the forum data in shared memory (memcache) for multi-server environments. It could be used on a single server but the performance increase might be trivial compared to a good cache on the mysql db since the core “engine” still has to load.

The only real cache that could speed up bbPress is a page cache like wp-super-cache which bypasses the WP engine entirely. It would have to be ported eventually. But that only helps for users that are not logged in and the idea of a forum is for people to be logged in and interacting.

Currently I cache parts of pages like the front-page tag cloud on my own installs but I have not released the plugin for that.

You’ll know when your query count goes down. You may not even have the bug in your version of the alpha. I think it’s only present in the newest trunk versions. If your front-page query count increases for every new tag you have in the tag cloud, then you have the bug.

There is also a bug I just fixed in bb-topic-views 1.6.2 but I don’t think you use that plugin.

Not only does the setting have no effect, 1.0 has a “reserved” option list which forces all foreign options (ie. set by plugins) to default to non-autoload, causing an extra query for each one unless they specifically add themselves to the auto-load list.

So other than hacking nearly every single existing plugin, you can try my workaround: