Drupal Association members fund grants that make connections all over the world.
The theme registry is maintained separately for each theme, however the bulk of the work done in _theme_build_registry() is the same regardless of theme.
This patch caches the theme registry for modules - one entry regardless of current theme, then once that's built, any number of themes are able to re-use that when building their own registry.
With the standard core install we're already building two theme registries - one for Bartik and one for Seven. There are different setups (domain access, og_theme) where a lot more themes might be in use.
A full theme registry build for one theme takes anywhere between 300-900ms and between 6mb and 23mb of memory depending on the site and whether an opcode cache is installed (although so many .admin.inc files are loaded by the registry building that it is often cache misses for opcode caches anyway).
The patch reduces this to ~50ms and ~500kb of memory for the second (and any subsequent themes) - in this case I cleared the theme registry, hit the front page with Bartik, then hit 'add content' which loads in Seven.
I'm attaching three files - a full rebuild in Bartik with the patch applied, a rebuild in Seven with the patch applied (note there are only two calls to _theme_process_registry() instead of 29 for that one), and an unpatched theme rebuild from a client site on Drupal 6 with over 200 modules installed - this code hasn't changed all that much since Drupal 6 so that gives an idea with a more complex site.
Theme rebuilds don't happen that often, but there are a couple of reasons this is worth optimizing:
1. A new Drupal user is going to rebuild both the Bartik and Seven theme registries within a few seconds of installing Drupal. While the time taken is variable (depends on opcode caches etc.) it's good for first impressions of Drupal if it's not horribly slow when you first start clicking around. This is the same thing as optimizing the installer.
Patch passes theme tests locally. Marking for backport since the change is entirely internal to _theme_build_registry().
2. If a site is serving a large number of requests per second, there can easily be a stampede on the theme registry since it's a single cache entry that's required to serve any page. This should make the stampedes cheaper at least, we may also want to add an explicit lock as well but the patch doesn't do this.
3. I know of a certain Drupal 7 install that allows Drupal themes to be created via the UI, this involves rebuilding the theme registry for one theme quite often, that particular use case should be improved.