[TYPO3-core] Regression in TYPO3 6.2 after introduction of composer class loader

[Helmut Hummel]

Hi!

Am 27.01.15 um 09:43 schrieb François Suter:
> Commit 15bde67 [1] which is entitled "Use composer class loader for
> better performance" introduced a regression in TYPO3 6.2. From what I
> understand some form of class mapping (new names to old names) is not
> happening anymore.

This has been fixed now with this commit:

https://git.typo3.org/Packages/TYPO3.CMS.git/commit/b2a9aeecd393a6a6f3fdb772bde8fff6e9f53582

We tested this in depth at the code sprint and fixed minor quirks caused 
by (widely used) third party extensions. As far as I can say, this 
implementation is rock stable now, but I'm happy for any feedback.

A few more words on what this change means, why it was done and why it 
was back ported to 6.2:

Class Loading and the Class Alias compatibility layer in TYPO3 6.2 is 
quite sophisticated, but nevertheless could cause some troubles 
especially when clearing the classes cache.


## Benefits we get from the new class loading

1. Performance (empty cache)
The class loading cache consists of one file per class and one 
additional file for each class alias. This could easily end up in having 
over 2000 files in this cache. Building this cache means writing 2000 
files, which can take quite a while on some systems.

Our new composer class loading strategy can load classes and set their 
aliases for *all* core classes or required extensions. This means that 
we can avoid writing 1719 files when hitting a 6.2 Installation with 
empty caches. This boosts up such requests by a lot.

2. Robustness
One major downside of the class loading introduced in 6.2 was the lack 
of robustness. The cache not only consisted of > 2000 single files but a 
few additional realted cache files. Some of the related cache files were 
used as "identifier" if the class cache files (the > 2000) themselves 
needed to be rebuilt or not. However if these related cache file 
existed, but only one (out of a few special ones) of the 2000 files was 
deleted, the whole installation was broken with a fatal like:
"Psr\Log\LoggerInterface not found" or "t3lib_extMgmt not found"
These errors still happened, even with a sophisticated locking mechanism 
which was added during TYPO3 6.2 development.

While for some classes, the cache files were re-built on request, this 
conceptually was not possible for classes (and aliases) required very 
early in the bootstrap.

The new class loading strategy makes these essential classes and aliases 
generally available, independent from caches or any runtime code. 
Classes and aliases are statically generated by composer and shipped 
with the core. Errors like the ones mentioned above are just gone.

This is one major conceptual shift: Instead wasting CPU cycles to 
evaluate what classes to load during runtime, we go the composer way to 
make them availble upfront, potentially adding a bit to better runtime 
performance.

3. Cleaner code
By using pre-calculated class composer class loading, we could remove a 
lot of require_once calls from the bootstrap and will be able to remove 
even more of them spread out in the code, because we can be sure that 
our class loading works starting basically from the 3rd line of executed 
code.


## Further implications and plans for the future

Our "old" class loader still exists and needs to be registered for 
optional core extensions and third party extensions. It'll still work 
like before, writing single cache files for each class during runtime.

But it is possible to define an autoload section (and alias map section) 
in an extension or the top level composer.json to generate a complete 
static class and alias map when installing via composer, rendering the 
old class loader obsolete. To stay as compatible as possible, this 
feature is however hidden behind an environment variable which needs to 
be set in 6.2

Enabling this feature also makes it possible to add additional libraries 
as requirement to your TYPO3 CMS 6.2 project's composer.json and just 
use them (their classes) directly in your code.

In the master branch this will be possible by default.

These changes not only provide direct benefits in speed and robustness, 
but IMHO define another milestone for our product, opening up for a 
broader PHP community.

Enjoy!

Kind regards,
Helmut

-- 
Helmut Hummel
Release Manager TYPO3 6.0
TYPO3 CMS Active Contributor, TYPO3 Security Team Member

TYPO3 .... inspiring people to share!
Get involved: typo3.org