OK – I think that was the first query before caching had taken effect, because I reloaded the page and got:
0.126 – 33 queries
Any ideas why the drastic reduction?
155?! Whoh, and I’m worried about 18 queries in my still-in-development plugin 
.
It would be much easier to say anything if there would be any link…
This query diagnostics plugin will tell you something. It could be ck’s originally. http://pastebin.ca/1182319
Everyone put this in your bb-config.php
$bb->load_options = true;
and that number will go down radically.
For some reason I don’t understand they refuse to make that the default and therefore bbPress just “lazy loads” each option as each plugin requests it.
If you are using the 1.0 alpha they still have a bit of work to do with query reduction as they rewrote half the routines and storage layout but left it unoptimized. For example each forum on the front page is loaded as a separate query and then the meta for each forum is loaded as a separate query. It’s a bit crazy because if you have a dozen forums that’s 24 queries but I have high hopes Sam or MDA will tackle that soon and do it all in just two queries.
Last but not least there is a serious optimization problem IMHO in all versions where bbPress will “read before write” every time a meta option is saved, regardless if it’s just been loaded and sitting in the object cache. I have to put a bit of extra code in all my plugins to work around this issue. The reason why they do that is to determine if they should do an INSERT vs an UPDATE because you can have duplicate keys on meta data by design and mysql can’t be told what to do if the key already exists. But there are better ways to do that – since 99.99% of the time it’s going to be an update since the data already exists – do an update and just check for a mysql error on the return (or count rows affected) – then do an insert instead that one time it’s needed.
