Here are some discussions and mentions around the web:

• an article on Weblog Tools Collection
• a forum post on WP Tavern
• twitter retweets

Sure, there are drawbacks to this method and it does require some more processing on the backend and it's not for everyone, which is why we should always strive for an even better solution.

I stand by my point of view that, for instance, my dedicated gallery shouldn't load for people who will never even go see my photos.

I think an ideal solution would be for WP core developers, who had a lot of experience designing WordPress' internals and who know what can work and what can't, perhaps Matt included, to get together and think about a better solution really hard.

Conditional loading similar to the one discussed here is already possible in the admin area, which creates dynamic hooks by appending page ids to 'admin_print_styles' and 'admin_print_scripts'. It is, however, still not good enough to be used more generically because those hooks rely on the page you are on, rather than the content of that page.

Another possibility is using a PHP technique called output buffering (ob_start(), ob_flush(), etc) that grants second chances to data that had already been echoed. It intercepts all echo and print calls and redirects them into a memory buffer, so instead of printing data to the page right away, you can now modify the header even if it had already been processed. It's like giving it a second chance.

Would it work for WordPress? I am not sure but I sure could use your feedback, devs.

• [WordPress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts
• Swapping Column Values in MySQL
• How To Dynamically Increase Memory Limits When Interfacing With WordPress Using XML-RPC (Windows Live Writer, Etc)
• How To Remove Inline Hardcoded Recent Comments Sidebar Widget Style From Your WordPress Theme
• How To Fix Incomplete WordPress (WXR) Exports

In this tutorial, I am going to introduce a WordPress technique that I believe was unpublished until I raised the question a few days ago on the WordPress forums.

In short, the problem I was trying to solve was plugins unnecessarily loading their JavaScript and CSS on *every* page of the blog, even when doing so would achieve absolutely nothing and the plugin wouldn't do any work.

Let me explain using this example:

• a code formatter plugin only does something useful when it sees a [code] shortcode in any post on the page.
• most of your posts do not contain the [code] shortcode as you don't include code snippets that often or you only started using this particular plugin recently.
• the plugin, however, loads the CSS and JS (which are most likely GeSHi and take up loads of space) on every page.
• these CSS and JS do absolutely nothing on most page loads.
• bandwidth is wasted, extra DNS and HTTP requests are processed, the browser is slowed down, and for what? For no good reason, other than the plugin author didn't know how to achieve this conditional loading.

If you think about it, there are many plugins that only do something once in a blue moon. Table of contents, text manipulators, galleries, sliders, etc, etc. If only they loaded their frontend code strictly when necessary, most page loads would suddenly become much lighter.

So what can we do to solve this? Let's look at a few techniques.

Loading CSS And JS In Place?

Here's one, albeit pretty bad, solution - only print the CSS and JS includes if and when you determine somewhere in the middle of loading the posts that the scripts and styles are indeed needed, then set a flag to avoid printing them again. In our example, that would be when the plugin detects the [code] shortcode.

This, however, is a mediocre solution because, while it's not a bad idea to load Javascript in the footer, CSS should be loaded in the header, otherwise the page might look unformatted until the CSS is reached.

Additionally, it's not the cleanest and most robust solution because you shouldn't be writing <script> and <style> tags manually but rather using wp_enqueue_style() and wp_enqueue_script() functions.

What's This About wp_enqueue_FOO?

Now, you might say: "What's this about wp_enqueue_style(), wp_enqueue_script(), and then hooking into 'wp_print_scripts', 'wp_print_styles', 'admin_print_scripts', and 'admin_print_styles' hooks"? You know about these, right? Right??

Allow me to explain this, in my opinion, greatest and most underused WordPress paradigm in a short refresher:

Enqueuing Alone Is Not Enough

Enqueuing is great for loading your JS and CSS but using it alone doesn't achieve the conditional behavior that we are looking for here.

This is a classic case of Chicken or the Egg, because WordPress makes only one pass through all of the content.

You see, since the header needs to be printed before the content, wp_print_scripts and wp_print_styles hooks are triggered before you even get to the posts. If you enqueue a script or style from within the 'the_content' hook, for example, the queued up scripts and styles will never get printed. It's too late to print them then anyway, as you're already in the middle of printing the posts.

The Solution

What we need to do is take a step back, before even printing the header, and then peek ahead.

Sure, this adds an extra pass over some data, but since no filters are applied during this process and if you avoid regular expressions (using stripos(), for example), this extra pass should be quite negligible.

The upside, however, can be potentially very substantial.

Credit goes to @white_shadow for the idea.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

add_filter('the_posts', 'conditionally_add_scripts_and_styles'); // the_posts gets triggered before wp_head
function conditionally_add_scripts_and_styles($posts){
	if (empty($posts)) return $posts;
 
	$shortcode_found = false; // use this flag to see if styles and scripts need to be enqueued
	foreach ($posts as $post) {
		if (stripos($post->post_content, '[code]') !== false) {
			$shortcode_found = true; // bingo!
			break;
		}
	}
 
	if ($shortcode_found) {
		// enqueue here
		wp_enqueue_style('my-style', '/style.css');
		wp_enqueue_script('my-script', '/script.js');
	}
 
	return $posts;
}

This simple function fires before the header gets printed, as it's attached to the 'the_posts' hook. However, this time it has full access to the posts' content.

I have tested this method and it works really well - if you have heavy scripts in your plugin, please do us, users, a favor and incorporate this logic into it.

Conclusion

In this tutorial, you have seen a method of loading scripts and styles for you plugin conditionally. This technique allows for less bloated pages and faster page loads.

Plugin developers, what is your take on this solution? Do you use another method? Please share in the comments.

• Follow-up To Loading CSS And JS Conditionally
• How To Remove Inline Hardcoded Recent Comments Sidebar Widget Style From Your WordPress Theme
• How To Dynamically Increase Memory Limits When Interfacing With WordPress Using XML-RPC (Windows Live Writer, Etc)
• How To Diagnose And Fix Incorrect Post Comment Counts In WordPress
• How To View A Specific SVN Revision In Your Browser

Introduction

Dear Skype,

you are great. You have the convenience of a nearby, well, convenience store and the UI that is acceptable to even an Apple fanboy (I'm not one, I'm just saying).

Skype also has a Firefox extension which finds all pieces of text that resemble phone numbers on web pages you are visiting and converts them into clickable Skype buttons . One click and you're dialing the number. The premise is great but the execution… When it comes to your Firefox extension, Skype – you suck. You really suck.

The Problem Bullshit

So what makes me say these mean things? Is it the fact that when simply searching Google for "skype firefox", one finds mostly blog posts and references to major fail? Or is it the fact that MozillaZine's Problematic Extensions page lists Skype as one of the buggiest?

Well, yes. Those are great, aren't they? However, what really prompted me to write this post is my own experience with this extension.

As I am getting into Android development nowadays, I read the Android dev guide quite a lot. Thus, it was no surprise that yesterday I was happily reading the page about Handling UI Events. What was a surprise, however, is that when I clicked over to the View API reference page (in case that page ever changes for documentation reasons, I also saved it here), my Firefox went into a painful agony and exploded in a few minutes.

What the fudgemonkeys? Let's do this again and watch the Process Explorer. 

This is what we call a memory leak – a prime example at that. In the screenshot above, the CPU usage spikes to 100% (shown as 50% because it's a dual core CPU), Firefox's memory usage jumps to around 2GB from 100MB, in 500MB/s increments. Finally, at 5GB total system memory consumption, either the OS kicks in or some major swapping starts to occur – I'm not sure which of the two is happening exactly but you can see it when the green CPU marker gets overtaken by the red one.

As I have a large number of extensions installed, I was dreading the next step: disabling them until the culprit was found. Ugh…

Sure enough, after about half an hour of starting Firefox, observing the memory leak, killing, and restarting it, I narrowed it down to the Skype extension. Somebody at Skype needs to fess up. And here's the kicker – it only exposes the memory leak in the following configuration:

If you turn number highlighting on – it's fine. If you turn name highlighting off – it's fine. But if you turn number highlighting off but leave name highlighting on – major fail.

The Conclusion

So where am I going with all this? Here is the summary:

• somebody at Skype doesn't know how to program
• this is the worst memory leak in a Firefox extension I've ever seen
• this extension is notorious for its crashes, bugs, and memory leaks
• keep using this extension if you're
  • a masochist
  • need to perform burn-in tests for your CPU or RAM

Have you had problems with the Skype extension? If so, share in the comments.

• Essential Firefox Extensions (Plugins, Add-Ons) And Tips – A Comprehensive Guide :: Part 1 :: Tips
• Meet Firefox For Mobile [Video + Feature Highlights + More Info]
• A Detailed Depiction Of The Job Interview Process At Google (by Peteris Krumins)
• Twitter.com Autocomplete, Auto URL Expansion, Auto URL Shortener, RT Button, Nested Replies, Inline Media Embed, Search Tabs, And More
• Essential Firefox Extensions (Plugins, Add-Ons) – A Comprehensive Guide :: Part 2 :: Pragmatic Extensions

I know that a multi-disk RAID array with a bunch of fast disks (15k RPM?) is probably the most important method of improving performance, followed by the amount of RAM, so I'm trying to find the best combination/balance of the two. However, server prices on the Internet range so much that I don't even know where to begin to tell a good deal from a bad one. I don't think SSDs can play a role here, because we need at least 200GB of usable space per machine. For comparison, we currently use the following spec: Dual quadcore Intel, 16GB RAM, 200GB RAID1 + 1TB RAID1 using SATA drives (eww?) in a 2U rack (a bit too chunky, isn't it?) made by Zantaz. It performs quite nicely but I think it chokes on the amount of writes way too early.

So, what does everyone think the best configuration is under $10,000? Bonus points if you can provide a link to the vendor site or at least a model number!

• AMD Plans Major CPU Price Drops Day After Conroe
• MySQL Conference: Presentation At The Kickfire Booth
• Beer Planet is Fast Again
• MySQL Conference Liveblogging: Optimizing MySQL For High Volume Data Logging Applications (Thursday 2:50PM)
• MySQL Slave Lag (Delay) Explained And 7 Ways To Battle It

• SQL_CALC_FOUND_ROWS and FOUND_ROWS()
• COUNT(*)
• MEMORY table
• if query cache is on, then it makes no difference
• if it's off
• Memory MyISAM is fastest
• FOUND_ROWS() is slightly slower than count(*)
• more in the slides that I'll add later

• SELECT … WHERE a UNION SELECT … WHERE b
  vs
  SELECT … WHERE a AND b
• index_merge wins

• composite index is faster
• of course, multiple indexes are more flexible than composite index

• …

• query cache disabled
• 100k rows
• now and 20 years back
• retrieval range between 50 and 365 days
• all data fits into memory
• UNIX_TIMESTAMP is worst
• DATETIME in the middle
• strtotime() fastest

• NOW()
• MONTH(NOW())
• MONTH('YYYY-MM-DD')
• DATE_FORMAT()
• SUBSTRING()
• all about the same if php benchmark script is used
• BENCHMARK() is very unreliable, the results vary a lot

• 3 different methods on mysql forge
• 2 UDFs and 1 using native functions
• query cache off
• 1K rows
• all rows have "/"
• count the number of "/"
• Marcelo's solution "COUNT_CHAR_OCCURRENCE": 4th place
• Garrett Hill's solution "countstring" (it's technically slightly wrong, because it doesn't account for multibyte characters): 2nd place
• Roland Bouman's solution using mysql functions: 1st place
• Jay's way: function in php: 3rd place

• BTREE is faster
• HASH uses less memory

• MySQL Conference Liveblogging: EXPLAIN Demystified (Tuesday 2:00PM)
• MySQL Conference Liveblogging: The Future Of MySQL (Tuesday 11:55AM)
• MySQL Conference Liveblogging: Benchmarking Tools (Wednesday 4:25PM)
• MySQL Conference Liveblogging: Performance Guide For MySQL Cluster (Tuesday 10:50AM)
• MySQL Indexing Considerations Of Implementing A Priority Field In Your Application

• polling based communication
• CPU used heavily even at lower throughput
• avoids interrupt and wake-up delays for new messages
• some good results in benchmarks
• decreases performance when CPU is the limiting factor
• 10% performance improvement on 2, 4, and 8 data node clusters
• 20% improvement if using Dolphin Express
• epoll replacing select system calls (Linux)
• improved performance 20% on a 32-node cluster
• send buffer gathering
• real-time scheduler for threads
• lock threads to CPU
• distribution awareness
• 100-200% improvement when application is distribution aware
• avoid read before Update/Delete with PK
• UPDATE t SET a=const1 WHERE pk=x;
• no need to do a read before UPDATE, all data is already known
• ~10% improvement

• previous recommendation was to run 1 data node per computer
• this was due to bugs, which are now fixed

• if there is a table that has a lot of index scans (not primary key) on it, partitioning this table to only be in one node group can be a good idea
• partition syntax for this: PARTITION BY KEY (id) (PARTITION p0 NODEGROUP 0);

• lock memory in main memory – ensure no swapping occurs in NDB kernel
• batching IN (…) with primary keys
• 100x SELECT FROM t WHERE pk=x;
• SELECT * FROM t WHERE pk IN (x1, …, x100)
• IN-statement is around 10x faster
• use of multi-INSERT
• similar 10x speedup

• multi-threaded data nodes – currently no benefit using DBT2 but 40% increase in throughput for some NDB API benchmarks
• DBT2 improvements to follow later

• Pentium D @ 2.8Ghz -> Core 2 Duo @ 2.8Ghz => 75% improvement
• doubling L2 cache doubles thread scalability
• choice of Dolphin Express interconnect increases throughput 10-400%

• 1-2-4 threads – linear
• 4-8 threads – 40-70%
• 8-16 threads – 10-30%
• decreasing scalability over 16 threads

• batched key access – 0-400% performance improvement
• improvement scan protocol – ~15% improvement
• incremental backups
• optimized backup code
• parallel I/O on index scans using disk data

• simple read, simple update, both transactional
• 72-CPU Sunfire 15k, 256GB RAM
• CPUs: ultra sparc-III @ 900Mhz
• 32-node NDB Cluster, 1 data node locked to 1 CPU
• db size 88GB, 900 mil records
• simple reads 1.5mil reads per second
• simple update 340,000 per second

• MySQL Conference Liveblogging: Portable Scale-out Benchmarks For MySQL (Wednesday 10:50AM)
• Setting Up A MySQL Cluster
• MySQL Conference Liveblogging: The Future Of MySQL (Tuesday 11:55AM)
• MySQL Conference Liveblogging: Applied Partitioning And Scaling your (OLTP) Database System (Wednesday 11:55AM)
• MySQL Conference 2008