Here is a list of ten important issues and what they do. Anybody who wants to make a difference in how well Drupal 4.8/5.0 performs will take the time to review and test these patches, easing the work of Dries, Steven and Neil in getting them into core.

• Split up the cache table. This would be a major performance win because invalidating the cache would be less expensive and would lead to fewer cache rebuilds.
• File-based caching. This is now possible as an extension of the pluggable caching system that has already been committed. The benefits of file-based caching are obvious; if your site's bottleneck is the database server, move the load to the disk drives instead.
• Include a robots.txt file. Drupal sites should always have a robots.txt file. I've been experimenting with web crawlers and watching what happens when they encounter Drupal sites. The results are not pretty. We needlessly serve a significant number of pages to each web crawler that comes along, even though they are unsuitable for search indexing (request a replacement password pages, for example). There are hundreds of web crawlers that come knocking, meaning each one will sap the same resources from your site with no benefit to you or them, just a higher bandwidth bill at the end of the month.
• Set a reasonable age for cached pages. Cached pages shouldn't be crawled and recrawled over and over again by Google, etc., but that is exactly what is happening. This patch tries to ensure that crawlers won't re-crawl a cached page unless it has actually been updated.
• Caching of more objects (blocks). There are still many things in Drupal that could be cached but aren't. This patch aims to find some of those areas and build a cache mechanism for them.
• Don't SELECT user uid = 0. Currently, Drupal does a database SELECT to load the anonymous user (uid = 0). This is needless since that user doesn't have anything to load. This patch avoids this, saving multiple queries.
• Allow administrator to set logging level for Watchdog. Watchdog entries can generate a huge number of database INSERTs. These are the most expensive and lead to a lot of overhead. For sites that value database performance more than watchdog logs, this patch lets you ratchet down the logging level and log only what you want, or nothing at all. Big performance gain by avoiding an INSERT on a large number of pages.
• Pluggable sessions handling and sessions caching. Digg.com (a site with *lots* of traffic) stores all of its sessions in a special RAM cache called memcached. This makes session handling super fast. The sessions table in Drupal, on the other hand, is often a failure point on busy sites. This patch guarantees that all of the session handling code is cleanly contained in one file, inculdes/session.inc, thus making it easier to replace it with a file that uses memcached, or any other type of custom session handling. The patch doesn't bring a performance gain in and of itself, but for those who want to deploy massive Drupal sites, it is a critical step.
• Better default 404 handling in .htaccess for files. At the moment, a 404 for an image, missing js, css or flash file generates an entire Drupal bootstrap and page generation. As we know, this can be 30+ queries plus all the PHP overhead. This patch introduces directives in .htaccess that let Apache return its own 404 error message for these missing resources while retaining the feature of a Drupal default 404 page for actual page requests. This made a massive performance difference on a client's site recently. This patch needs more work, so please jump in and lend a hand.
• No more table locking. Drupal introduced table locking to avoid race conditions, but in doing so created a performance disaster. This patch tries to solve both problems and will result in much better performance for MySQL users.

As you can see, there is a lot of work to do, and not much time (3 weeks to the code freeze!), so please, invest in your Drupal future, and take a look at them.