@t-p,
The short answer is no, I (not we) are not looking at this.
The article seems to apply very arbitrary ‘measures of impact’ and ranks plugins in an arbitrary manner too. For example, compare the data in the first table for Subscribe2 and for W3 Total Cache.
Subscribe2 uses the same amount of RAM in the admin area and no more than that on the front end, the same number of SQL queries (0) loads in the backend faster and uses significantly less hooks. Subscribe2 is red and W3 Total Cache is green. That makes no sense to me.
Additionally, there seem to be no factoring for the complexity of the plugin. bbPress massively changes the function of WordPress from a blog into a bulletin board – of course it’s going to slow things down.
If the article had given specific recommendations for exactly WHERE things can be improved as opposed to drawing a line in the sand and saying this side is good and this side is bad then I’d happily take a look but frankly I feel this analysis is meaningless without any consideration of what the plugins are actually delivering.
Moderator
t-p
(@t-p)
If the article had given specific recommendations for exactly WHERE things can be improved
They have: http://www.dev4press.com/2011/tutorials/wordpress/practical/how-to-optimize-plugin-loading/
@t-p,
I’ve posted a response to MillaN asking for more information about his results. Please read it for more but looking at his table it seems his ranking system is arbitrary and random. subscribe2 appears to perform better than some other plugins he has chosen to test and yet he ranks it worse.
Moderator
t-p
(@t-p)
@mattyrob,
Thanks for the reply. Yours is one of the couple of plugins I use and I like it very much. Let’s see what the tester has to say to your inquiry.
@t-p,
The summary of the reply as I’m reading it is that Subscribe2 makes efficient use of RAM, SQL and hooks BUT becuase it’s essentially one large file it is the authors opinion that by breaking it into several files and only loading these when needed would make the RAM overhead less. (It’s reported as 1.4meg currently).
I’ve replied that for me Subscribe2 is a hobby and I’m not a coder by profession. It’s a hobby and supposed to be fun for me. That said I am intrigued so my project now for version 8.0 is to split the code as suggested and see if this does indeed reduce RAM.
This has some consequences though, it will slow down all future development as I will find it harder to track several files. It will take time now too away from other development and support to split the files, check they work and then test that it remains at least as efficient as before but hopefully considerably better.
If there are no improvements or perhaps improvements with some trade offs the project may get shelved too!
