[Fabian]

Hi,

I have bbpress installed with a url prefix, everything is under /forums/. I noticed when I just access my frontpage, the plugin causes a site slow down of ~100ms. I have 25 plugins in total and I compared bbpress page load time with the page load time with the other 24 plugins activated.

bbpress does not render anything outside /forums/, so 100ms, I’d say even 20ms, CPU time per request is not justified.

I did a profile of my WordPress setup, which revealed that the main file ‘bbpress.php’ include()s 36 others scripts, takes up to 4MB of memory. Most of the time is waste in the ‘init’ hook, ~40ms.

Can you please fix this?
I tried conditional Plugin loading with Plugin Organizer, but it seems to break the rewrite to the /forums/ URL and it just redirects to the frontpage.
So basically, if the request it not within /forums/, bbpress should only set the rewrites, and this should be done within a couple of milliseconds.

Thanks!

[Robin W]

can I just clarify that your site takes a tenth of a second longer to load with bbpress – yes ?

[Fabian]

Yes its 0.1 seconds comparing a WP wihtout any plugins, and WP+bbpress. Its not negligible, I expect websites to respond within <0.5 seconds for a good user experience.

There are 2 issues (which apply for most other WP plugins):

1. The impact of bbpress gets bigger with more plugins enabled, because activated plugins have hidden dependencies to each other.
Lets say we have another plugin with 0.1 seconds slowdown, and bbpress with the 0.1 s, the total site slowdown is usually greater than 0.2 s. By using the add_filter() API, plugins actually call each others functions.

2.) Each request bbpress includes almost 40 scripts, the PHP parser parses all of them (lets take opcache apart), and then does not generate a single byte of HTML. So its just wasting server disk I/O, and CPU.

[Milan Petrovic]

1. That is simply not true. I developed many plugins for bbPress, and I always do extensive benchmarking of bbPress and various plugins, and if you have 25 plugins or if you have 5 plugins, bbPress has the same impact on WP regardless. If two websites add 0.1 seconds slowdown, you can’t blame one of the plugins for what other is doing.

2. That is completely irrelevant to loading performance. It is possible to merge all files any plugin has into one huge file. A number of files don’t have too much impact on the loading, and it is even recommended to have a lot of smaller files to help with the code organization, improve loading of what is needed when it is needed (for the most part). WordPress loads about 200 files on average for each page request, and even more on the admin side, and I have seen plugins that load 100 or more files. Size of files have more impact on performance, then the number of files. And with modern servers using SSD discs and a lot of memory, files loading is negligible.

The biggest impact of performance of any plugin has to work with the database in any way (getting posts, filtering). And yes, bbPress up to version 2.5 was not best optimized, and it was on the slower side when dealing with large topics or large forums. Version 2.6 (currently in Beta/RC stage), has significant performance improvements related to database operations, loading posts and processing them.

PHP has Opcache, and other performance related tools for a reason: PHP is not compiled, it is interpreted, and that is always a slower method for doing things, and PHP needs help to make things faster. It is a good thing to have and use Opcache or Memcached. For instance, my website without Opcache uses 60MB for PHP process on average, with Opcache that goes down to 12MB. WordPress without Opcache uses about 20MB on its own, bbPress adds about 5MB, WooCommerce adds closer to 10MB, BuddyPress around 6-7MB. Huge and complex plugins always need memory to work, you can’t expect to run 25 plugins and keep memory to a zero. That is why we have systems to optimize PHP, we have cache plugins.

Once the bbPress 2.6 is released, I will do a new benchmark to compare 2.5 to 2.6 and see how much gains are there when using bbPress with a forum having a large number of topics and replies. But, from current testing I am doing with 2.6, it is much faster than last 2.5.

Milan

[Fabian]

1) It is true and I’ll show you some more precise benchmarks on this for a concrete example. Take the filter bbp_map_meta_caps, it’s within a filter recursion, where the filter fires it self again. The recursively fires 4 times with bbpress only. Now if another plugins does the same, it could get up to 16. Plugin run times include each other through the filter api. In worst case you can’t just add them to each other, they bias by some non-linear function that is definitely not O(n).
Your point is true, that you can’t blame a plugin for being slower in conjuntion to others. But, you as a developer, should avoid that other plugins can slowdown your own plugin, by minimal intrusion into the WordPress plugin API. And bbPress does not have this minimal intrusion. Of course it is a big software product, but there is high potential to conditionally hook into WP only on pages it needs to.

2) No its not completely irrelevant. I wasnt clear enouh here, I’m not referring to file count, but yeah -how you said- file size or LLOC. Were not talking about vulcanizing scripts. You’re right, the PHP interpreter got very fast and it should not matter, but consider:

a) Only the inclusion of bbpress main file makes PHP allocate about 600 KB. Thats a lot, considering 0 output bytes. And this happens on every request, every REST.

b) Think about who runs a WordPress site, not people that have a dedicated high performance server. Usually its a webspace in a VM. These systems can power hundreds of sites, so the webserver does not just read 500 files at the same time, but lets say 10000. This lowers the chance to find the same PHP code in some cache between subsequent requests. The code size per request starts to matter here.

b) It is a style thing, I dont want my programs to load 1MB code without using it. And yeah, there are many plugins that just follow WordPress style to include everything, but this does not mean it is a good style to follow. Unfortunately, there is no well known code metric that covers this. WP was created in darker times of PHP, without autoloaders. Why do we have them now? I dont get it why so few plugins properly use them, it takes a day to refactor your plugin and another to test.

bbPress is not doing bad. It could just be more minimal if the forum is just a smaller part of your website. I dont expect 25 plugins to allocate 0 memory, but I expect 25 plugins not to clog my dashboard and frontpage, where I do not want them to load. I want them to do what they are supposed to do on specific pages within the front- and backend.
Its true that woocomerce is the worst.
I could optimize it though. It only loads on the shop frontpage, on the checkout page, on product pages, specific ajax actions and REST endpoints. The cart can be XHR, or one can keep on loading the plugin once a cookie is set. This technique makes the wp-admin dashboard fast too.

(I’ll back with the benchmarks)

[John James Jacoby]

The problem of conditionally loading the PHP files will go away when we can start to officially support autoloading for versions of PHP greater than 5.2.

With BuddyPress, we did move to supporting autoloading when it’s available. bbPress has fewer files, and is a simpler piece of software, so my preference would be to keep it a bit more pristine and not include the same conditional support until it’s a general requirement for running WordPress.

Anything we can do to make bbPress more performant is definitely encouraged, so I appreciate you noticing, and taking the time to start the discussion here.

[Fabian]

@johnjamesjacoby thats not true, WP has a “polyfill” for autoloading, and actively uses it on every request, even on legacy PHP 5.2. So autoloading is officially supported.

These are first numbers about the impact of an unconfigured bbPress on a fresh WP server response time:

PHP 5.6 + opcache : +35 % SRT
PHP 7.0 + opcache : +28 % SRT
PHP 7.1 no opcache: +28 % SRT

As you can see bottleneck is loading and parsing. Note that the speedup of opcache in PHP 7 is about 6x.

[Fabian]

Yes, BuddyPress registers its autoloader, but includes most files through BP_Component::includes() anyway. Thats only half-way implemented.

[John James Jacoby]

https://core.trac.wordpress.org/ticket/41134 seems relevant here.

@fabian If you wanted to take a stab at sprucing bbPress up with its own polyfill for autoload support, I’m happy to help test and implement.

We should probably open a ticket on our Trac as well.