Name for taxonomy and custom post type has messages explaining the required format for a name. I have changed this and it’s now the same message only in bold red letters. Plugin will also attempt to clean the name when saving: remove illegal characters and make the name lower case.

If you have any more problems, please report them in the forum or in comments.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

To check the results from first part of the benchmark, go the this post. There you have test setup and results for memory usage, page generation speed and executed SQL queries. Second part of the admin test is in this post.

Tests results presented here are average values from 20 measurements. Also, only active plugin in all tests was GD Press Tools Pro. Adding more plugins have no effect on the overall difference in terms of memory use or execution time. Showing more tests that have the same result in the end is not needed.

Test 6: PHP Used memory on site

Similar to the admin side, WP 3.0 uses more memory on the site side. Difference is about 1.6MB, and it’s not much in this normal setup with no plugins active (expect for GD Press Tools).

Used Memory: Again WP 3.0 uses more memory as expected

Adding plugins to the mix will have as a result more or less the same difference in used memory, or slight increase to 2MB of more memory. But even with more than 20 plugins on site side WP will still use much less memory than admin side. Still, 32MB for 20 or more plugins is not enough.

Also, used memory with Kubrick and 2010 themes in WP 3.0 is almost the same, with new theme needed a bit more memory, considering new features added in it, this difference is not important.

Test 7: SQL queries executed on site

Code optimizations in WP 3.0 were beneficial on site, and WP 3.0 will run less SQL queries for same result from WP 2.9.2. This is only couple of queries, but from server point of view, very important.

SQL Queries: Once again WP 3.0 is better than WP 2.9.2

With less queries, SQL execution time is lower, but that didn’t help WP 3.0 in the next test, with overall time needed to make a page increased.

Test 8: Page rendering server side on site

With both themes WP 3.0 is slower than WP 2.9.2 by 10-15%, in all the tests. This difference is just about the same as on the admin side. And it’s to be expected, more code is added to each execution (more memory is needed), and PHP needs more time to run all that.

Server side execution: WP 3.0 is slower than WP 2.9.2

Due to some added features new Twenty Ten themes is slower than Kubirck. Surprising result is on the single post page where WP 3.0 with Twenty Ten was faster than with Kubrick. Getting post data seams to be optimized better in WP 3.0 and that shows here.

More tests: Client Side?

Results for both WP versions would be the same (with the difference in JavaScript, since they use different versions of jQuery). So, these tests will not show much here, results are almost 100% the same.

Conclusion

Progress has it’s price. And for WordPress 3.0 that is more resources needed and slower execution. With todays available servers and faster Internet, this is not a big factor, considering what you will get after you upgrade to WP 3.0. So, not to point only negative side of the benchmark, I will write conclusive article in the next few days that will put this values in better context and real evolution of WordPress in it’s current release.

Bottom line: upgrade to WordPress 3.0 as soon as possible (as soon as you are sure that all plugins you use are compatible).

Favorite Actions

Only few days after major 2.0 release, GD Custom Posts And Taxonomies Tools gets another Pro version that includes few fixes (widgets) and some very interesting new features. Lite version is also updated and cloud widget bug is now fixed, and few things updated.

Right Now

As you can see on the image on the right, now each custom post type can be added to the Favorite Actions menu in the header, and as displayed on the image on the left, it can be added to dashboard widget called Right Now showing number of items for that post type and a link to edit page as it is done for my custom post type called Document.

This can be done with any custom post type, and these are only the first to so called Special Features that plugin implements. To set them, edit the custom post type, and you will see a new Settings elements called Special. It’s a drop down allowing you to select special features you want to use for that post type.

Special Features

More features will be added with next versions, and if you have suggestions for them, please leave a comment. And, special features are only available in Pro version of the plugin.

Other changes in this version include fixed cloud widget and removed integration with Google XML Sitemap plugin for taxonomies, because that plugin supports taxonomies for quite some time now.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

Expanded taxonomy meta box

New version of GD Custom Posts And Taxonomies Tools is finally ready. Sorry for a delay, but I needed some time to test new features and also decide what to do about one more feature previously announced. Lite version is also released with some minor changes.

As you can see on the image on the right, there are two new elements for Post Tags and all other non hierarchical taxonomies you might use. Clear ALL is available for some time now, and the other is brand new Yahoo Suggest. It will take post content and submit that to Yahoo, and will get back tags from the content. You can add all tags, or refresh it, or click on individual tags to add some of them.

Other new feature is on the taxonomies and custom posts panels. New option is added to display function that will create taxonomy or custom post type even if you don’t use the plugin.

Another planned feature was new widget with all taxonomies, but that’s been moved to another version, because I wasn’t satisfied how it turned out. After it gets reworked, it will be included, most likely in 2.1.

If you notice any problems with new features, report it in the forum or leave a comment.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

To check the results from first part of the benchmark, go the this post. There you have test setup and results for memory usage, page generation speed and executed SQL queries.

Test 4: Generated Page Size and JavaScript

This test will show how the big pages are, including HTML, CSS, JavaScript and images send to the browser. There is a slight increase in the data send, but this not a big deal, considering the results from Test 5 you can see later. More JavaScript shows that interaction is better, and more elements are now using AJAX or animate for better user experience.

Generate Page Size: WP 3.0 makes slightly larger pages

Page JavaScript: WordPress 3.0 adds slightly more JS

This is not very important test, because standard Internet connections today are broadband everywhere, and that can handle a bit bigger pages. But, it’s a good idea to keep the track of everything and don’t allow to grow out of control.

Test 5: Client Side Execution

Well, new jQuery and better JavaScript code payed of and the WordPress 3.0 executes faster now. But, this is highly dependent on the browser and there are big differences in speed. My measurements are done with Firefox 3.6.3, and here is the chart:

Clientside Page Execution: WordPress 3.0 is faster

WP 2.9.2 is a bit faster on post edit panel, but in WP 3.0 there is much more going on there, more AJAX, so this is not a big surprise. In all other cases WP 3.0 is faster. But, if you want it fast that don’t use Firefox! And don’t use MS Internet Explorer. Opera 10.5/10.6 is 3-4 times faster than Firefox, and in Opera a page renders usually under 3 seconds. Google Chrome 4 is 2 times faster than Firefox, and Chrome 5/6 is 4 times faster. Safari 4/5 is 2 times faster than Firefox. Internet Explorer (even IE8) in some cases can take 20 seconds to render some pages in WordPress.

For administration of all my WP websites I use Opera, and I always get frustrated when I have to use Firefox because it slows me down, since I am so used to Opera and speed it provides. Browsers race in improved JS speed is a good thing, and with every new version Opera, Chrome and Safari keep getting faster. I don’t know what’s wrong with Mozilla, but Firefox right now is very slow compared to these 3 browsers, and I hope that Mozilla will make some important changes and get back in the speed game with Firefox 4 (for 3.7 is already too late, and it’s not faster than 3.6).

Conclusion

So, WordPress 3.0 is faster now and gives much better user experience, and more things are changed and improved to provide better administration features. AJAX is used much more, and there are more interactive elements all over. Despite some problems with memory usage and other things I talked about in previous part of this benchmark, there is no doubt that WordPress 3.0 is the best and most important release of this platform in last 2 years.

Most issues so far were caused by the lack of memory for PHP causing not only upgrade to fail, but some memory hungry pages also. Also, compatibility of many old plugins caused upgraded websites to break, pointing to a big problem with most plugins that are not in development anymore but still widely in use and preventing many websites owners to move to new and better WordPress.

Test setup

Tests are done using fresh installations of WP 2.9.2 and WP 3.0. Only one plugin was used, and that is GD Press Tools Pro 3.7 that is used to perform some of the measurements for the benchmark. At the end I did some testing using 10 plugins. My test server uses Apache 2.2.11, PHP 5.2.9 and mySQL 5.1.37. I have tested following (and most important) admin pages: Dashboard, Posts, Post Edit and Comments.

This first part will focus on WordPress administration because most of the issues are there, and this time PHP used memory, page loading and number of executed SQL queries.

Test 1: PHP Used Memory

WP 3.0 uses more memory than WP 2.9.2. On all pages WP 3.0 uses 2MB more, and on some it can use between 3-4 MB more than in WP 2.9.2. This difference is the same regardless the number of plugins active.

Used Memory: WP 3.0 uses 2MB more than WP 2.9.2

Activating 10 plugins, memory rises by 8MB. On this website that has 20 plugins active, WP uses 41MB on average. Most WordPress websites use 15 or more plugins, and that means that standard setups with 32MB for PHP are not enough to run WordPress. This is very important requirement for WordPress, and yet it’s not stated anywhere on official website, and most users will find out about this the hard way and unprepared. WordPress.org MUST state somewhere how much memory you will need under different setups, because right now WordPress 3.0 can’t be run at all on default PHP installation with minimal 16MB.

Another memory issue is upgrade from 2.9.2 to 3.0. If you have more than 11-13 plugins active and only 32MB and you are on host that prevents changing of PHP memory, automatic upgrade will surely fail. I tested 2 of my websites locally with memory limited to 32MB, upgrade failed in every case. Also, if you upgrade your website with all plugins disabled first, you need at least 30MB (!) for PHP for auto upgrade. So, realistic minimal PHP memory requirement for WordPress is 32MB. With many plugins active, you need at least 48MB or 64MB for PHP. And this all will make a lot of problems to all users on shared hosting.

Test 2: Number of SQL queries

This is very much improved in WordPress 3.0, and on average WP 3.0 executes less queries and that’s good because your mySQL server can run with more requests in the same time. Both number of queries and time needed for all of them is faster in WP 3.0.

SQL Queries: WP 3.0 is better than WP 2.9.2

This points to many optimizations behind the scenes, and new WordPress will have less impact to mySQL server performance than previous versions including WP 2.7, WP 2.8 and WP 2.9.

Test 3: Page Loading, server side

Some time is gained by lower mySQL execution time, but it’s lost on the PHP side, so overall loading time is a bit slower than before. Difference goes up to 10%, but in some cases loading time is the same. Number is average of 10 measurements.

Server side execution: WP 3.0 is a bit slower than WP 2.9.2

Conclusion

This is the first part of these tests. Second one is coming tomorrow, and the third will be in a couple of days. These tests show you measured facts about new WordPress, but you mus be aware of all the changes in new WordPress and everything added, because all that comes with the prices: performance. You can’t add tons of features and expect nothing to change. But, I think that big problem is that existing WordPress users were not prepared to that fact and many of them blame WordPress developers for the problems they had with upgrading to WP 3.0.

Over the last 2 years, WordPress needs more resources with every new version, but there is nothing about that on official WordPress website, and until you experience the problem first hand, you have no idea that WordPress needs more and more resources to run. And all that is just bad work from everyone working on WordPress.org that needed to prepare users for the new release and what they can expect. Same mistake with every release, and that’s not good.

First important improvement that I was interested in was the fact that WP 3.0 requires less resources than WP 2.9. WP 3.0 Beta 1 uses some 20% less memory than WP 2.9. Speed has not really improved much, and some pages are faster while others are slower, but it’s good to see that after WP 2.7, 2.8 and 2.9 that constantly needed more resources, we finally see an improvement.

For last few years I work exclusively for WordPress, and I don’t plan to change platforms any time soon. All my plugins are either fully WP 3.0 compatible, or will be so before WP 3.0 is released (GD Press Tools 3.2 and GD Custom Posts And Taxonomies Tools 1.6 will be released soon).

Adding new Custom Post Type

Custom Posts

Adding support for custom post types is the most important addition for WordPress. It allows you new level of freedom to create content for the website and not to make complicated queries to determine what posts are for what using custom fields or categories.

In the last few days I have expanded GD Taxonomies Tools to support custom post types (to be released in a day or two), and I am already building new section on this website for centralized documentation using custom types and my plugin. For the most part, it’s implemented OK, but there are some inconsistencies and some overlapping with custom taxonomies that should be ironed out (assigning custom post types to taxonomies and assigning taxonomies to custom posts, incomplete and confusing edit link feature), but overall, this is the most important thing WP got with 3.0.

Network / Multi site

Merging with WPMU is long overdue, and it works really good. I had no problems with it so far, and I hope that people who have to migrate their WPMU website to new WP3 will be able to do it without loosing data. Right now I have noticed problems with bbPress and deep integration in WP3 when network mode is on, and I expect too see new bbPress soon that will fix compatibility issues.

New default Theme

OK, I don’t know about you, but I simply hate new theme. I know that simplicity should be main thing for default theme, but there are many much better simple themes that could be included and improved to new WP3 standards and functionalities. When I have seen this new theme for the first time, old Kubrick started to look real good again.

But…

I am not going through all the features added in WP 3.0, there are plenty of articles all over the Internet praising new version (and don’t get me wrong, WP 3.0 is very good, much better than previous releases), but I found none that actually points out what’s really wrong with WordPress, not only with this version, but wrong for a long time.

Content Management

It’s fine if you have 15 categories and few hundred posts tops. But, what to do if you have 500 or more (deeply nested) categories and several thousands posts? Assigning categories to posts, changing things is so painful with current interface, at times almost impossible to do. We need some integrated management that will show all relevant elements on one screen (minimized if not used, widgets panel is good example of the organization we need), with drag’n'drop support.

But, that’s not only problem. WordPress is getting exponentially slower when number of posts start to grow. Some of the post update functions when used on large number of posts in the same time will likely crash your WP or eat up all available resources. Number of queries executed with any operation working with posts is huge, and works fine only if you work with post at the time.

I work on very large website for a client with now over 12.000 posts, and with 1000 new added each month, and every few days I have to write new code that will work on these posts with direct SQL queries, because using WP functions fails every time when things need to be updated. And website is on very fast VPS server.

Complete content management interface, and that includes post/pages/custom_post_types editors, taxonomies editors MUST be rewritten soon to allow flexibility and speed in management operations.

Interface Elements

None of the WP grids (posts, categories, users…) don’t allow sorting!!! Too make things worse if you activate networks in WP 3.0, Site Admin grids are sortable, since they are moved here from WPMU. So, the code exists for that, but regular WP can’t use it. Rendering code for grids is not consistent, and it can’t be used for plugins, so if you are making plugin you need to copy table structure to make it look right. All the standard elements used need to be standardized and public so that plugin authors can simply extend base grid class and get own grid. Some WP elements are now turned into classes and Widget class is great example of that, but interface must be standardized.

I am working on GD Star Rating 2.0 right now, and I have made class for rendering data grid that is easy to use and reduces code needed and makes your code cleaner. And many plugin authors had to do this on their own.

Theme/Plugin Editor

Either make it right or remove it. They can be used if you have plugin with few files, all in root folder. But if you need to edit more complex plugin there is no way you can do that. Finding file to edit is almost impossible, and you need to manually type file paths in URL to get what you need, and that doesn’t guarantee that editor will allow you to edit that file. In WP 3.0 I even think that editor is more confusing than before.

Conclusion

I really expected that some of these things will be part of WP 3.0, and I think that WP 3.0 would be better off delayed until end of 2010, and to have enough time for these elements to be done properly. I don’t know what is planned for WP 3.1/3.2, but nothing is more pressing than adding proper content management. Without that WP will never get rid of the blog label, and people are not going to accept it as real CMS. Right now WP is stuck somewhere in between these two and much needs to be done for WP to realize it’s full potential, and just saying that WordPress is full CMS, is not making it so, there are still ways to go before that gets to be true.

Anyway, I am looking forward to official release of WP 3.0, and I will use as much of new things as I can, and I am still hoping that we are going to see real and radical changes to some very outdated WP features.

Long time ago, there were only few browsers available, most of them (except for Opera) were pretty bad. But then, we got a great browser called Firefox. And soon after that we got another tool, more important than any other tool for web development. This tool was extension for Firefox, and it’s called Firebug. And while we had Firefox 1.0, and Firefox 1.5 everything was fine. But then, they made Firefox 2.0. And if it wasn’t for Firebug, that was the point I wanted to delete Firefox and never use it again.

It was slow, used too much memory, and was unable to handle many open tabs for a long periods of time. They were releasing updates left and right, but nothing really changed. The things were made worse once the 64bit Windows was used more and more. I started using 64bit XP few years ago and using Firefox was simply frustrating. And in that time I started using Opera as a main browser because everything was much better than Firefox. Except one thing. Opera had nothing like Firebug was. And I had to use Firefox still… Yes, I know, there are many new features added over the years, but with all that there are many more new problems.

Good thing was that I wasn’t the only one with these problems, and some people released 64bit version of Firefox. Most extensions were not working, but it was still much better than regular Firefox. Another good thing was that after some time, Mozilla finally admitted that memory management in Firefox is bad and that they will fix that in Firefox 3.

Guess what? They didn’t. On Vista x64 Firefox 3 is slower than IE7 or now IE8, takes forever to load and crashes regularly very, very often. To make things worse, Firebug was causing as many problems as Firefox on it’s own was. Endless alpha/beta version, problems and crashes, but still nothing comes close to Firebug. Or so it looked like. But all other major browsers were on the rise, and things were changing for better.

Opera released first preview version of Dragonfly development tool that over time has grown, and it can do almost everything Firebug can. Major problem with Dragonfly is that it looks differently from Firebug, so it will take some time getting used to. Take into account that Opera is extremely stable  browser. On my desktop machine that’s working without restart for more than 20 days now, Opera 9.64 is running from the moment Vista booted (yeas, it’s running 20 days without problems), without restart, with 10-20 tabs opened at all times, and uses some 200MB for all that tabs. On laptop I use Opera 10 Beta 2 and things are also very smooth considering that’s still in beta stages. At this moment I have 34 tabs (I am not kidding, working on few projects right now, researching and testing) opened in Opera 10 with Dragonfly active and it uses 270MB. Good luck trying to open 34 tabs in Firefox (2, 3, 3.5) and let it run for a few hours. I tried that my self (with same 34 urls opened in Opera) with both 3 and 3.5, and it crashed after 21 tabs on 3 and 28 tabs on 3.5. FF3.5 in the moment it crashed used 730MB. Browser closed and the firefox.exe process still remained running taking full CPU load and I had to kill it using task manager.

Google Chrome browser also has development tools, but they are still not very usable, but that will change. Chrome is also very stable browser and it doesn’t cause problems. Many people I know have switched to Chrome as a major browser.

But the real frustration is trying to debug something with Firebug either with FF3 or FF3.5. In the past 4-5 hours I FF crashed 25 times! It works with a single tab (debugging some things in WordPress and jQuery), but still I hit reload few times, and everything stops. I close it, but even the window is gone, FF process is still working, eating a lot of memory. And I have only Firebug extension installed, nothing more. Many people told me to disable extensions if Firefox is causing troubles. But disable all extensions, and what you get? What’s the point of Firefox without extensions. Many things you need them for, you already have built in Opera. And on Firefox I use ONLY Firebug, nothing more. If I disable Firebug, I don’t need Firefox anymore. And Firebug is the last reason I have Firefox installed at all.

My best guess is that most of the problems Firefox has are caused by the fact that it’s not working well with 64bit operating systems. And that’s used as a excuse a lot. But that’s not right, because Opera and Chrome are 32bit programs running under 64bit, and they work fine. Also, 90% of all programs still have only 32bit versions and rarely they have problems. And for Mozilla finding excuses simply is not an option since they want to rule the browsers market. They were announcing 64bit version when 3.0 was announced. Nothing. Again with 3.5 another announcement for 64bit version. And, again nothing. But, if the 32bit version was written as it should, they wouldn’t need 64bit version.

I know that many people are using Firefox just fine. They need 2-3 tabs opened, they are not developers and they don’t need browser to run all days, for days. But I need, and most of the developers do. So, there you have it, I really, really hate Firefox.

Go download Opera and give it a try. You will be pleasantly surprised.

But, before you go on, here is the reminder of previous posts:

• Test environment setup [ read more ]
• Results from administration tests [ read more ]
• Results from testing blog pages [ read more ]

Administration memory usage

Administration

First batch of tests will focus on WP administration pages. I used the same setup for these tests, and comparison between two versions of WP are on this first chart. As you can see, dashboard page now uses some 5MB less memory in both clean version and with all plugins active. Main reason for this is because feeds are now loading data through AJAX only if they are needed.

Pages are now prepared by PHP much faster, and this is noticeable on, more or less, all administration pages. Generated pages sizes are mostly the same size as with WP 2.8, with few exceptions where the generated page is much smaller, like with the dashboard, because feeds are now not a part of the page. Same speedup is visible on general settings page, and now time zone settings are loading very fast.

As you can see not all pages show memory decreasing, but that is to be expected, not all parts of WP 2.8 were problem, only some of the pages needed to be fixed. But as I said, many of the improvements are visible all over the administration. For the past few days I have been using 2.8.1 on my blogs, and I am very pleased with latest changes.

It’s important to mention, that this time I had no problems with auto upgrade as I had with updating from 2.7.1 to 2.8, so that’s also a big plus for 2.8.1

Blog Pages

The other part of the test is testing of actual blog pages. Again, many things depend on the theme you use and on the loading optimizations theme might (or not) use. As I said before, very few themes right now are improved in that direction. So, I decided for this WP 2.8 against WP 2.8.1 tests to focus on default theme and number of queries executed.

Number of queries on blog pages

As for the other tests like size of the page and used memory, there is almost no difference between two versions. But, as I said in first post on the subject, WP 2.8 is already excellent as the blog pages goes.

But in most cases, WP 2.8.1 needs less queries then WP 2.8. I am not sure exactly what is done to cause this improvement, and I really don’t care, as long as WP 2.8.1 is better. And less queries it takes, means that less resources will WP use, and server will be able to serve content to more visitors in the same time.

Last week I have published similar tests for WP 2.8 and my GD Star Rating plugin, and you can see in that post how much SQL queries will that plugin add to the blog. Tests are done to show the value of cache and prefetch methods I developed into the plugin to minimize the queries.

Conclusion

Now that we have WP 2.8.1 released, there is no more reasons for you to wait with upgrading your blog(s). WP 2.8.x uses more resources then previous versions, but that is, in my opinion, good trade off for much better interface, much easier to use panels for posts and comments, better dashboard, better user interaction and most important faster blog pages that your visitors see. If WP 2.8 was problematic in terms of using too much memory, WP 2.8.1 solved all that problems and even improved in some areas. Overall, this is the best release of WP yet, and a good sign that next versions will be, as expected, even better.

I hope that I will be able to complete (soon) testing of JavaScript performance and testing of some of the plugins to complete the series of benchmark posts trying to give you a better look at WP performance.

I made few changes to each of the WP installations so that the measuring rendering time is more accurate. Also, I changed few things in GD Press Tools also, and the Arthemia theme for the next part when the benchmark will be done for the actual blog. For some of the plugins I used older versions for WP 2.6.5, as recommended by the plugins authors. All results displayed on the charts are mean value from 5 measurements. I used Opera 9.64 browser for time and memory tests, and Firefox 3.0.11 with Firebug 1.3.3 for size of the output (personally I don’t like Firefox at all).

For test configuration and setup check the previous post: Benchmark Setup. On all 3 charts, first 3 columns for each page is for WordPress without plugins (only GD Press Tools is active), and the next 3 columns are for WordPress with all 15 plugins active, list of plugins in setup article.

Why benchmarking?

The reason I made these tests is because it’s obvious that no one in WordPress development team didn’t do anything like this. In fact they even claimed that WP 2.8 is much faster, and that’s simply not true at all. Take a look at this page, and notice that one of the highlights is speed of the admin pages. Speed can be gained using Turbo with Google Gears, and in that case browser needs less time to render the pages. But Opera, Safari, Chrome and Firefox are very fast already and will render very fast anything you throw on them. Browsers can’t speed up server response time. And Gears is not an option for Opera or Safari users (hopefully we will see better Gears browser support soon), not to mention problems I had with Gears in Firefox and that I don’t plan to start using it any time soon.

WP 2.6.5 is used only as a reference, in most cases you can’t really compare it with WP 2.7 or WP 2.8 because interface and some other things are rewritten, but it’s interesting to see how WP 2.6.5 compares to latest releases in terms of performance.

Page load times

First series of tests are to determine how much time PHP and server needs to generate a single page. Some of the things were problem to measure with WP 2.8, but I will get to that later. Even when the pages are partially loaded from cache this time is more or less the same. I noticed some 10-20% drop in WP 2.8 for reloading the same page, but that’s still too high.

WordPress load times

WP 2.8 is more than 2 times slower than previous two WordPress versions. On some pages difference is even bigger. I have measured 4 pages, 3 are WP native pages, last one is Settings panel from GD Press Tools, and it’s the fastest in the group because it doesn’t load a bunch of things most WP pages do.

But, there are some pages that need much more time. General settings page takes more than 10 or 15 seconds to load, because for some reason WP developers decided that the time zone list needs to be populated from WordPress website. This list could been included in the WordPress code. Right now it gets really frustrated to change any of these settings and need to wait all that time. That’s simple unacceptable.

Used memory

Things are pretty much the same with memory usage. As you can see 15 plugins add a lot to the memory used. WP 2.6.5 uses much less memory in both cases but that’s not a big surprise.

WordPress memory usage

WP 2.7 and WP 2.8 have totally rewritten interface and because of that it needs more memory. But the problem is with WP 2.8 that more or less should have the same memory usage as WP 2.7 because the changes were not that significant to cause this difference. Dashboard is the biggest problem and it uses some 25% more memory than WP 2.7. On some pages like the the general settings I mentioned earlier in some cases I noticed memory leaks and memory use increases to 45-55 MB. On one instance loading failed meaning that it exceeded preset 64MB. And again, that’s most likely caused by the timezone code.

WordPress output size

Page size

Finally this is something where WP 2.8 is actually better than WP 2.7. Again, WP 2.6.5 pages are smaller because of the different front end, but it’s interesting to see how much the interface ‘costs’.

WP 2.8 generates smaller pages compared to WP 2.7 mostly because of better optimization of JavaScript and CSS loading and joining several files into one. And in the same time that’s one of the reasons for slower loading and increased memory usage with WP 2.8.

Conclusion

There was a discussion on Weblogtoolscollection website about using 1 or 100 plugins, and it’s obvious that number of plugins active will increase used resources and time needed for page to be rendered. Another post that will investigate this much deeper. It will take some more time to prepare but it’s coming soon.

Based on all this is clear that in terms of speed and memory usage WP 2.6.5 administration is much better than the latest WP versions. On the other hand these are not actual pages that blog visitors see, and next post present results of blog benchmark under same condition, so I am not going to give some definitive judgement right now. I know a lot of people that still use WP 2.6.5 because they can’t increase memory every time WP is released. When WP 2.8.1 is released I will do a benchmark against current WP 2.8, to see if indeed developers managed to solve memory usage increase and lower speeds.

I use WP 2.8 on all my blogs right now, but I must say that I am not happy with performance of the administration compared to older versions. Interface IS much better, and to some point I understand and accept that the performance is a trade off for the interface and better work flow. But only to a point. I will be very disappointed to see WP 2.9 some 7-8 months down the road that instead of 40MB needs 50MB or more to work.

So, tell me what you think about data presented here, and about your own experiences with last 3 versions of WP, and especially with WP 2.8. And stay tuned for more benchmark results.

To begin all this, I will be using 3 WordPress version. With each version you can see the size of the installation without wp-content folder:

1. WordPress 2.6.5 (4.2MB)
2. WordPress 2.7.1 (5.3MB)
3. WordPress 2.8 (6.7MB)

All 3 versions will be set the same, all will use exact duplicate of this website, including Arthemia Premium theme, all plugins, posts, comments, settings, pages and everything else:

1. Posts: 34
2. Pages: 16
3. Comments: 215

After inserting all posts, with no plugins activated, I measured the size of databases for all 3 WP installations. WP 2.8 has significantly larger Options table mostly due to the new transient settings and new feeds format. I will post another similar chart after all the tests are done. And here is the list of installed plugin on all 3 test WordPress version.

Database Sizes

1. Akismet 2.2.4
2. GD Press Tools 1.4.0
3. GD Simple Widgets 1.2.0
4. GD Star Rating 1.4.7
5. Google XML Sitemaps 3.1.4
6. HeadSpace2 3.2.28
7. MiniMeta Widget 4.2.0
8. SABRE 0.9.0
9. SEO Booster Lite 1.6.5
10. Sociable 3.1.3
11. SyntaxHighlighter Plus 1.0b2
12. TinyMCE Advanced 3.2.4
13. Twitter Tools 1.6
14. WordPress.com Stats 1.4
15. Wordpress Download Monitor 3.1.4
16. WP-Slimbox2 0.9.7.1

GD Press Tools is always active an all test blogs and with this plugin, and benchmarking code added in it (only for these tests, it will not be added as a standard plugin feature) all measurements will be taken. All tests will be done on localhost setup on MS Windows Vista SP2 64bit with XAMPP 1.7.1.

1. Apache 2.2.11
2. PHP 5.2.9
3. MySQL 5.1.33

Test machine is very fast, AMD/nVidia based with strip mode RAID arrays and a lot of RAM:

1. CPU: AMD Phenom Black Edition 9850+ (QuadCore)
2. RAM: DDR2 8GB Kingston HyperX 800MHz
3. Motherboard: Gigabyte GA-M750SLI-DS4 with nForce 750a SLI chipset
4. HDD: 2x500GB RAID1, 2x160GB RAID1

So, now you have all the basic facts, and expect first post with benchmark results in the next 3-4 days.