Improve performance of locale cache

Having per page caching looks like a good idea to me, we could also use some smart caching for this new feature, in queue: http://drupal.org/node/141461 (dynamic object translation).

I lthink what we really need here is some smart caching that learns with experience and maybe generalize it for any kind of object. The caching mechanism may decide, after the page has been rendered, whether to update the cache if new objects have been loaded or not. Also, we should predefine, depending on the kind of page, which kind of objects are worth being cached or not.

I.e., for a node page, we could have locale caching and taxonomy term caching, depending on the node type.

Well, just brainstorming a little bit, this is actually quite complex... But the locale caching could be really a good starting point.

Drupal 6 now has a capability to turn off the cache temporarily to measure what strings are used exactly. This way, contributed modules can fine-tune the string cache to the strings actually used, regardless of the length of the source strings. (This cache would be overwritten everytime the locale cache regeneration runs, which is when editing strings or importing new translations, but this does not happen on a stable site).

Better ways to cache in core would still be nice to investigate.

Subscribing...

subscribing as well.

#152901: Caching (per user) for authenticated users already has some code to make the locale cache per path, using a "collect during the request / save at the end" mechanism that we could generalize to other areas (the registry lookup cache already works that way, an hypothetical path cache could may also work this way...).

I have been looking into this issue last week which gave me some problems:

* Saving the translations based on admin / not admin is possible however... it will cause alot of writes when the cache is cleared. For every string which is not in the cache would require the cache to be overwritten.

* Having a page cache for translations seemed like the other best option I could think of. This indeed gave quite some speedgain when saving the cache for one path. However you do not want for all of the 'node/x' path a different cache. There for I have been looking into saving it by the registered path 'node/%'. The problem I have with this is for retrieving the path I can not work with the API 'menu_get_item()'. This translates the menu item and goes back into the 'locale' function. At the moment I have these solutions:
- Custom query for fetching the path
- Have a second cache with all the menu items translated

Both these solutions provide a second query which is proberly more expensive because of roundtrib times then one single query with a large result over a direct connection to the database server.

My next actions will be to check out the issue Damien posted and work on a solution with a single query for the path cache. If someone knows anything smart, please let me know!

Just to mention a few related issues that may really help with locale performance:
#365934: Handle big texts / module text files / readable and localizable / get rid of _user_get_text()
#299050: Help System - Master Patch
#361614: Make locale() read only?
If one or more of these get in, the number of strings and the length of them in locales table will really go down, so we may not need this one.

For the reasons mentioned above, makin this postponed for now.

The cache has been highly reworked in Drupal 8 in http://drupalcode.org/project/drupal.git/commitdiff/7f6f46786a6194dbc33c... so I don't think this should apply anymore. Possibly in older versions.