Your requests in a comment below please.

1,init,3472960,73672
2,admin_menu,4090776,617816

Wait a minute! Between initialisation and admin_menu hooks being called, 600KB of RAM is consumed. I didn’t pay much attention to that earlier on because it was just there. Now I think I’ll take a closer look. If that figure could be reduced, the WP admin working set might drop below the magic 4MB limit.

What consumes 600KB between init and menu?

Tracing The Path Between Initialisation And The Admin Menu

Action ‘init’ is triggered at the end of wp-settings.php, which is required by wp-config.php, which is required at the beginning of wp-admin/admin.php.

Action ‘admin_menu’ is triggered at the end of wp-admin/menu.php.

The code that needs to be examined lies between lines 19 to 54 of wp-admin/admin.php. The quickest way to find out what’s happening is to add more of my little memory probes. Here’s a Dashboard memory dump to get your teeth into.

php dump.php admin-memtest-20060529-151631

0,plugins_loaded,3347456,3347456
1,init,3417504,70048
2,post-admin-functions,3850776,433272
3,post-admin-db,3949256,98480
4,post-registration-functions,3978648,29392
5,post-auth_redirect,3978880,232
6,post-nocache_headers,3979000,120
7,post-update_category_cache,3979000,0
8,post-get_currentuserinfo,3979168,168
9,pre-menu,3980288,1120
10,admin_menu,4037104,56816
11,admin_head,4003152,-33952
12,admin_notices,4025184,22032
13,update_option_rss_42109a30548dd2078da9009859b481aa_ts,4348832,323648
14,activity_box_end,4376616,27784
15,update_option_rss_0ff4b43bd116a9d8720d689c80e7dfd4_ts,4466824,90208
16,update_option_rss_867bd5c64f85878d03a060509cd2f92c,4967152,500328
17,update_option_rss_867bd5c64f85878d03a060509cd2f92c_ts,4650208,-316944
18,admin_footer,4545680,-104528
19,shutdown,4485632,-60048
20,/~paul/wp-memtest/wp-admin/,4481344,-4288

The inclusion of wp-admin/admin-functions.php consumes the most RAM followed by the database “abstraction” layer in wp-admin/wp-db.php. Given the nature of these files, I am not at all surprised by the scale of the memory usage so I can’t imagine I’ll find much to trim away. Best to be sure though.

Why Do The Admin Functions Need 400KB Of RAM?

No reason I can see. It’s just a big file that costs 400KB to load.

Why Do The Database Functions Need 100KB Of RAM?

This file constructs an object that connects to a database. If that only costs 100KB of RAM, fantastic!

My probes are being gathered during the admin interface but not dumped. I reckon wp-admin/admin.php is a good place to register my shutdown function which dumps the memory probe data.

First Run

I do like it when things work first time. Especially this time, as the results confirm something I already knew.

php dump.php admin-memtest-20060529-132332

0,plugins_loaded,3343480,3343480
1,init,3413632,70152
2,admin_menu,4031776,618144
3,admin_head,4000568,-31208
4,admin_notices,4022600,22032
5,update_option_rss_42109a30548dd2078da9009859b481aa_ts,4346512,323912
6,activity_box_end,4374360,27848
7,update_option_rss_0ff4b43bd116a9d8720d689c80e7dfd4_ts,4464528,90168
8,update_option_rss_867bd5c64f85878d03a060509cd2f92c,4964856,500328
9,update_option_rss_867bd5c64f85878d03a060509cd2f92c_ts,4647880,-316976
10,admin_footer,4543160,-104720
11,shutdown,4483112,-60048
12,/~paul/wp-memtest/wp-admin/,4478824,-4288

The Dashboard is a monster! It uses 4964856-3343480=1.6MB of RAM, a fifth of the total! I hope this is a limited phenomenon.

Write A Post, Post A Picture

Hmm… I appear to have introduced a bug. On uploading the picture for my post, the picture upload box says This script was not meant to be called directly. It worked before. Maybe a different picture. Odd, the second picture worked fine. I’ll try the first one again.

Why does my image named emmas-flower.png upload OK but my image named emmas flower drawing.png does not? It might be the spaces in the filename, so I’ll replace them with dashes. Upload emmas-flower-drawing.png. No, same response. This script was not meant to be called directly.

Is something wrong with the image? Oh. Yes. Duh! emmas-flower-drawing.png is 12.7MB in size! Not a hope in hell of uploading that. I’ll need to drop it in size, to under 2MB, which is the standard upload file size limit. A quick “file save as…” later and I now have a rather more svelte 750KB JPEG. Upload that. It works, almost. Although I can clearly see a thumbnail of the picture, the options menu tells me there is no thumbnail associated with the image. Whatever.

After a bit of faffing, I post some pictures and a bit of text. What memory probe goodness have I got?

WordPress Write Post and Inline Image Uploading Memory Use

I have 15 probe files so I must have been doing more faffing than I thought. There are a lot from the inline uploading, as I expected. I get the feeling that I’m losing probe data due to the admin interface program being executed more than once per second. The reading I was after, the actual saving of a post, is as follows:

php dump.php admin-memtest-20060529-135413

0,plugins_loaded,3399288,3399288
1,init,3472960,73672
2,admin_menu,4090776,617816
3,check_admin_referer,4043952,-46824
4,publish_post,4065600,21648
5,save_post,4241208,175608
6,wp_insert_post,4241208,0
7,edit_post,4270256,29048
8,publish_post,4270256,0
9,save_post,4271456,1200
10,wp_insert_post,4271456,0
11,shutdown,4262984,-8472
12,/~paul/wp-memtest/wp-admin/post.php,4262224,-760

Nothing unusual.

Minor Changes To The Probe

I ensure that the dump output filename is unique.

Clean Sheet, Once More With A Post And Pictures

No need to bore with the details. Overall, WordPress uses memory efficiently, apart from the Dashboard.