Appearances

The Header option allows you select which image should appear in your header with ease.

The Background allows you to define a color for your background or an image, it doesn’t seem to allow for more controls than that with the default theme.

The Menu option allows you to create a custom menu system. Definitely a nice touch. You define your elements, and include the custom menu as a widget into your theme.

The theme included is definitely an improvement over the older themes. It’s a more general design that you see in alot of wordpress sites, and should suit most of everyone’s basic needs.

Creating Posts

When creating posts you can define a featured image. The image will appear on your homepage and category listings, custom header, or other location if your theme supports.

Memory Requirements

My biggest issue the new version, which is still an issue with the previous versions, is the memory requirements. A fresh install of wordpress takes up to 10 Megabytes of memory to run for a single page request. That’s insane. The wordpress team really needs to make some headway on improving the memory requirements of wordpress. I’ve read their recommendations on the subject, and they all boil down to increasing the memory limit for php (especially when you use quite a number of plugins), or getting a bigger box. This is only a half-solution, and doesn’t solve the entire problem. The other option of caching the php code is fine, but that increases the running httpd processes on your server, there by eating up more memory.

Conclusions

I’m seeing some good improvements with wordpress which makes me continue to use it. When it comes to memory requirements thought, I’m not too thrilled. I hope to find another system with the same or similar functionality and customization. If you’re on a shared host, the memory issues can bite you later on when your site gets popular, of if you’re running too many plugins.

I hope the wordpress team really addresses the memory usage issue, and makes some more performance improvements to WordPress. I would recommend to them the following:

• Caching the wp_options table to a file on the filesystem and/or support for memcache.
• General support for memcache.
• Move the rss_feed data that gets left in the wp_options table and move that to another table.
• Not to clone the wp_query object. I don’t know why they do this, but having two of them just takes up more memory.
• Eliminite the older code in the codebase. There are numerous references through out the files for old pieces of code that have been superseded by the same function under a different name.
• Allow for more exposure of the underlining data from posts, comments, and other areas, so there aren’t as many plugins that get created.

I’m a big fan of a small code that does things efficiently. Why would I be any different about wordpress? I decided to open up the first file wordpress calls to see what other files get included. As a result, I find a long list of files that are loaded just to display a page in wordpress. Below is the output of what I found. Every file that is indented is called from the file that proceeds it in loading. Here is what I found:

index.php
	./wp-blog-header.php
		wp-config.php
			wp-settings.php
				WPINC . /compat.php
				WPINC . /functions.php
				WPINC . /classes.php
				if (wp-content/object-cache.php)
					wp-content/object-cache.php
				else
					wp-content/cache.php
				WPINC . /plugin.php
				WPINC . /default-filters.php
				WPINC . /streams.php
				WPINC . /gettext.php
				WPINC . /l10n.php				

				require (WPINC . '/formatting.php');
				require (WPINC . '/capabilities.php');
				require (WPINC . '/query.php');
				require (WPINC . '/theme.php');
				require (WPINC . '/user.php');
				require (WPINC . '/general-template.php');
				require (WPINC . '/link-template.php');
				require (WPINC . '/author-template.php');
				require (WPINC . '/post.php');
				require (WPINC . '/post-template.php');
				require (WPINC . '/category.php');
				require (WPINC . '/category-template.php');
				require (WPINC . '/comment.php');
				require (WPINC . '/comment-template.php');
				require (WPINC . '/rewrite.php');
				require (WPINC . '/feed.php');
				require (WPINC . '/bookmark.php');
				require (WPINC . '/bookmark-template.php');
				require (WPINC . '/kses.php');
				require (WPINC . '/cron.php');
				require (WPINC . '/version.php');
				require (WPINC . '/deprecated.php');
				require (WPINC . '/script-loader.php');
				require (WPINC . '/taxonomy.php');
				require (WPINC . '/update.php');
				require (WPINC . '/canonical.php');
				require (WPINC . '/shortcodes.php');
				require (WPINC . '/media.php');

				require (WPINC . '/vars.php');

				load my-hacks.php is file exists.

				load plugins if active.

				require (WPINC . '/pluggable.php');

				load the locale_file for language.

				require_once(WPINC . '/locale.php');

		WPINC . /template-loader.php   (WPINC is defined in wp-settings.php)

Wow, that is a very long list of files to get called.

I decided to take this a further and look at the rendering time and the memory used for loading a page. I found the following for this website:

• Loading the homepage: Memory Used: 6,277,732 bytes; Time to Render Page: 0.5902 seconds.
• Loading a post: Memory Used: 6,229,616 bytes; Time to Render Page: 0.1445 seconds.

6 full megs to load a page! The rendering time I’m not too crazy about either. Now, there are ways to improve this by using caching for the pages, and a PHP accelerator to speed up the code, but the vanilla loading of wordpress taking up this much memory and time seems slow and excessive. Granted, this is running on a VPS, so the rendering time might be more in line with a VPS. This install of wordpress is a vanilla install, no additional plugins, and I’m using a version of the default theme with a slight modification to it.
The next thing I did was to try out the other site I manage on wordpress. The numbers for this other site was more interesting:

• Loading the homepage: Memory Used: 9,410,144 bytes; Time to Render Page: 0.0910 seconds.
• Loading a category: Memory Used: 9,448,096 bytes; Time to Render Page: 0.2936 seconds.
• Loading a post: Memory Used: 9,388,744 bytes; Time to Render Page: 0.1707 seconds.

Now the server that this other website sites on is a 1 Dual Core Xeon @ 2.4Ghz, 2GB of Ram, and good IDE drives. The memory usage is higher, but that site is using a number of plugins.

I’m definitely curious as to why wordpress is using so much memory in both cases. I’m working on a project right now that one of the items I’ve built for it is a backoffice admin running in PHP and a propritery framework. I’ve looked at the numbers for the page times and memory usage, and right now, It’s no where near wordpress’s times or memory consumption. The page load times for the admin are in fractions of a second (ie: 0.0051 to 0.0779), about 1/5 the time of wordpress on average. The memory usage for the admin is in range of 750K to 1,275K. Still alot less than wordpress.

This large use of memory by wordpress can have a negative impact when a website received simutaneous connections, there by limiting the concurrent connections a website can received. On this site, I don’t think I could survive a digg/oprah/slashdot effect, even on a small scale. There has to be a way to improve the basic install of wordpress to be more efficient.

One thing I did that did result in a drop of memory usage, is to remove a number of rss entries that are stored in the wp_options table. I just did this on the other site, and that removed about 600K from memory. The problem is, these rss entries will return. There’s something in wordpress that queries these rss fields and stores them in the wp_options and gets loaded into the wordpress object. I wish I knew why. This is something that should either be disabled completely, or at the very least, removed from the wordpress object, because they are not needed for use of a website.