Locale Cache

Locale Cache module provides more efficient and flexible locale data (translations) caching. Based on code from the core D6 locale module.
You will probably get most benefits of this module only using a fast cache backend like APC, Memcache, Redis, MongoDB, etc.
Requires small patch to core to make it use our function instead of locale().

List of improvements over D6 core behavior

1. Long strings are cached too in per-string entries, so after some time all strings are in cache and we skip the database completely.

   This can result in significant performance gain if the cache backend is much faster than database. At minimum, this can lower the load on your database.

2. Configurable string length limit for the main locale cache (like D7).

   Strings longer than the limit are long by the module terms. By changing this value you can balance between the size of the main locale cache (thus php memory usage), and number of additional per-string requests for long strings.

3. If a new string is found, the main locale cache entry is updated only if we are actually going to cache the string (in the main cache).

   Core mindlessly clears the cache without checking.

4. Shorter version of string (a hash) can be used as an id for the main locale cache entry.

   This can save some memory (both for php and for cache backend) and bandwidth at the cost of processing time (calculating the hash). If for some reason you are CPU-bound, it makes sense to keep this disabled.

5. As a result of (4), long untranslated strings can be cached in the main cache too.

   This feature can be both good and bad, depending on many factors. If you want to minimize cache backend access at the cost of increased memory usage, you can try to enable this. It only makes sense to enable this when hashing for source strings is enabled.

6. Main locale cache can be set to rebuild only on cron.

   Say, you've added 100 new strings (that fit in the main cache) to your site. In core, in a worst case scenario locale cache would rebuild N=100 (!) times, resulting in a major load increase. With this feature enabled, worst case scenario is N =~ (total time to discover new strings) / (cron interval).
   Note that this feature doesn't break anything, it simply delays rebuilding of the cache. New string translations keep working with only difference: they are not cached until next rebuild.
   Turning this feature on is recommended for production systems, where most translations are done, with only minor additions from time to time.

7. Locale cache "stampede protection"

   While the locale cache is rebuilding, parallel requests still use the old cache. In core parallel requests bombard the database during rebuild.

Known Issues

There's a bug in core cache (database) backend, which breaks the module logics: #1302286: Default database cache backend doesn't serialize boolean values. The bug converts untranslated strings to "1".
This is generally not a problem, because using DB cache backend with this module is pointless anyway. If you encounter this behavior in other cache backends, please report it as a bug to the maintainer of the problematic cache backend module.

Notes

While the module doesn't break the API, with some settings it can surprise other modules which make assumptions about default locale() behavior, so it is not guaranteed to work well with all translation modules out there. Some testing and feedback is needed in that area.
Benchmarks are also welcome.
The module has variable-based settings, including debug mode - see README.