[TYPO3-core] Cachingframework implementation for lang sysext

[Christian Kuhn]

Hey,

On 06/29/2011 03:54 PM, Björn Pedersen wrote:
> Maybe the whole logic is to complicated:
>
> When will the ll-files change:
> a) if an extension is installed/updated
> b) if they are modified by hand

We should answer some questions to decide how a caching layer for lang 
should look like:
- Is the parsing process 'expensive' at all? Is this profiled? I the 
answer is a definate 'yes', we can benefit a lot from caching.
- Does it maybe make sense to rely on the first 'in memory' cache alone? 
This would invalidate all clearing issues and we still have a cache for 
consecutive calls of keys to the same ll file.
- How many ll files are typically parsed in a frontend / backend access? 
For FE this probably depends heavily on the number of plugins that are 
added to a page, but for BE I'd guess these are not too many, what do 
you think? Do we have some numbers?

For the 2nd level cache itself: The current patch uses the fileBackend. 
This will also trigger at least one filesystem request per ll file. If 
you want to use the file backend for some reason, we could maybe also 
think about using the PhpFrontend for this cache: This way we create a 
.php file with the parsed target array, and we can require_once() it. 
The nice benefit is that every php opcode cache will suppress the 
filesystem access after the first require_once() to this file and we 
will probably have a pretty quick solution.
BTW: We will need and get a generic phpfrontend cache in core sooner or 
later anyway, for example I'd like to use it in the autoloader already.

For the cache invalidation: Until now we are trained that any BE actions 
are 'non-cached', so until now if we changed a label, the backend 
immediately recognized the label change. In the FE we are already 
trained to clear caches frequently when developing, or we add &no_cache 
param to the url to circumvent this. This is what people nagged with the 
current implementation: The lang keys are not automagically refreshed if 
we change a label anymore.
But I think Björn is correct at this point: Labels only change during 
development, never (or very seldom) in production. From a performance 
point of view I'd argue that effective caching in production is more 
important than automagic cache clearing during development. Thus I'd 
vote to have no cache clearing at all to reduce production overhead. For 
development there is also be a very simple solution to switch off the 
cache layer: Use the nullBackend in development context.


My 2 cents
Christian