[TYPO3-core] Taming the Performance in 6.2

Mathias Schreiber mathias.schreiber at wmdb.de
Thu Nov 7 10:22:33 CET 2013


Quote: Thomas Maroschik (tmaroschik) wrote on Thu, 07 November 2013 08:31
> Since the introduction of the PackageManager PSR-0 support is there for 
> Flow and Composer Packages. 

I thought of not "support" but "only way to do things".

> But it does not help that much as the right 
> package path for the classname has still to be determined. 

The good thing is we can actually bend PSR-0 towards our needs.
So if we decide something that works out in our favour, we should do that.
If we think of TYPO3 as a vendor and keep extensions in mind we will basically have two paths to resolve.
[Keep in mind this is brainstorming things to start off a discussion]
If the Vendor is TYPO3 we will look in sysext.
If it is not, we look inside of typo3conf/ext/
Arguably we could still support typo3/ext/ but this is a risk I am willing to take.

So new \Typo3\Core\Blubbel() will resolve to PATH_site/typo3/sysext/Typo3/Core/Blubbel.php
The "/Typo3/" can be argued about though.

new \Wmdb\Supersearch\Indexer() would resolve to PATH_site/typo3conf/ext/wmdb/Supersearch/Main.php

new \TtNews\Main() would resolve to PATH_site/typo3conf/ext/ttnews/main.php

Now here's what the autoloader will do:
if(substr($classname, 0, 5) === '\Typo3') {
  $rootPath = PATH_site/sysext/typo3/;
} else {
  $rootPath = PATH_site/typo3conf/ext/;
}
try {
  @include $rootPath.doSomeStringStuffHere.php
} catch Exception

This way we can get rid of all the file_exists things which cost FS calls.
And if the file isn't there it will fatal anyways with require as we do it today.
The only thing that bothers me is the error suppression, I am not really sure if we need this.
But suppressing the error is cheaper than having a FS call IF Notices and Warnings are disabled in PHP.ini

Now how do we handle legacy stuff?
I can assume we all agree that ext_autoload should be present.
So we could use the info stored in ext_autoload to build a "classic" mapping on top of our "auto-determination".
I think this way is fair enough since those folks in need of high performance are not forced to use that mapping, IF they code clean with namespaces.
So if the try fails we could look LOAD the mapping file (if not done already) and then look up classes by mapping.

I know, it s a bold proposal, but we have the chance to do big changes.
People think they have to touch all extensions anyways.
So if we do breaking changes, let's do the whole nine yards.

What do you think?


More information about the TYPO3-team-core mailing list