What about a very active buddypress installation where we can’t use usual page cache? Is caching DB queries in RAM useful (e.g. for 5 Mins)? can you suggest a method?

Best,

marie

There’s no way that it uses just 5 hooks. It uses hundreds. I know that for fact, because we hook to several dozens of them as well.

Any chance that you didn’t configure the e-commerce functionality or are not using a theme that loads products?

As far as e-commerce plugins are involved, I think that it’s a wide enough topic to warrant a complete side-by-side analysis of fully loaded e-commerce sites.

And that is the point of all this, not how much memory plugin uses, but how much it can use if it was optimized.

Comparing a plugin like Contact Form 7 with Gravity Forms is simply not a valid comparison. The functionality, capabilities and feature set of these 2 plugins is vastly different. Comparing simple plugins which do not contain very much functionality with fully functioning APPLICATIONS in their own right like Gravity Forms, WooCommerce, etc. is like comparing apples and oranges.

The larger and more complex the application, the more code is involved and the more resources will be used. This isn’t a reflection on how good or bad the application is as far as code quality, it’s simply going to require more server resources.

I think comparing such a large number of WordPress plugins to one another as far as load time impact and memory utilization is simply an unfair comparison when it comes to the larger, more complex and feature rich plugins.

The truth is “plugins” like Gravity Forms, WooCommerce, etc. aren’t really just a “plugin”, i’ve said it many times that they are full blown applications that run on top of WordPress just like iPhone and iPad apps run on iOS.

Many of the statements you make about performance and improvements are true. Just remember that it’s incredibly difficult to add completely new functionality at little to no performance cost, let alone 8 huge new features like BuddyPress provides.

Have mercy.

One small issue with your example PHP code though – you should be using single quotes not double. Double quotes force PHP to evaluate the text for contained variables. Small point but as this article is about efficiency, the example code should also be efficient!

Regards, Julian.

Of course I’m going to defend my plugin! I’m quite open to criticism if I believe it’s fair criticism.

The purpose of this article is about assessing the load time of plugins as assessed by RAM usage, SQL queries, hooks used and time taken. All of this was done using another plugin – so very objective. I feel that Subscribe2 scored comparatively well against other plugins.

BUT, it was given a rating of “Bad optimization results, must be improved” purely based on the fact that it is one file with one class.

No, forgive my defensive stance but that’s not very objective now is it? To define a series of tests, get your results and then essentially ignore them because subjectively you feel the plugin code could be arranged a little better.

Then, to top it all since I’ve started looking at splitting subscribe2 into several sub-files I have realised I would have to buy the benchmarking plugin to see if it makes any difference. If this really if for plugin developer benefit, how about giving free access to the benchmarking code?

I’m not a coder, and can only “script” in PHP (in my own opinion), but this stuff is something I had to learn. Heck, the basic info is in the Wikipedia article…

Opcode caches and such may require some knowledge of the underlying stuff, and those are often needed when the sites and CMS get bigger. Plugin optimization and code quality are an issue for a site builder like me.

I expect that all PHP/WordPress developers should be informed about the way PHP works.

That’s maybe because you expect that PHP/WordPress developers have some level of training in coding and/or PHP.

I have none. This is a hobby for me and the last time I formally learned anything about computer languages was dBase3+. I spend enough time remaining up to date for my day job in healthcare as this pays my mortgage. As I said before, I need to keep it as simple as I can for me as from my perspective this is supposed to be something that’s fun and that I enjoy.

That includes users on shared hosting, small VPSs, large VPSs, dedicated servers, load-balanced environments, and perhaps even globally load-balanced environments. Focusing mostly on the most common context, shared hosting, is a smart move—but assuming that just because a WordPress blog is popular that it won’t be using your plugin is a mistake too. (I manage servers for several sites like this.) Assuming your plugin will only be run by technical users on servers with ample resources is silly.

> [A] plugin is not installed/activated unless it needs to be plugged in[.]

MillaN wrote: “One of the early steps in the WordPress loading is to load plugins. WordPress will get the list of all active plugins and it simply use PHP include function to load main plugin file.” I believe he’s absolutely correct here. *All* activated plugins get loaded for *every* request, even admin requests. (Please correct me if I’m wrong, folks.)

If you have parts of code needed for both front and back end (as any plugin would need), you put that code in a file loaded on both sides. You need one file for admin only code and one for front end only code. And main file to load these 3 files based on the location. This is simplified way to make the code optimized, depending on plugin size and features it is usually fragmented further.

You are basically saying that Subscribe2 uses too much RAM as it loads as a single class – despite the evidence you also present that indicates that this class only hooks where needed, makes few unnecessary SQL requests and does not massively add to page load times.

Maybe I’m being overly defensive but that seems a bit harsh to me. Personally, I find the code much easier to handle in one file containing all the functions rather than trying to split it out. You see a great number of the functions I have are needed on the front end and the admin area. Splitting into 3 or 4 files would just results in always including 2 or 3 of those files with the others being essentially empty.

I will however test your theory and see if splitting the files out does reduce RAM use. I still cannot understand how a plugin script of less that 200kilobytes in size needs 1.4megabytes of RAM to run though!