[TYPO3-core] Taming the Performance in 6.2

[Thomas Maroschik]

Am 07.11.13 10:22, schrieb Mathias Schreiber:
> Quote: Thomas Maroschik (tmaroschik) wrote on Thu, 07 November 2013 08:31
> 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 you bend a standard to your needs you are not implementing that 
standard anymore. You are then just compatible to a subset of the 
standard. And I don't think we will drop that again because many people 
from the community asked for composer and thus PSR-0 support.

> 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

This is not the way it works since ages. You can override any core 
extension except core in typo3conf/ext and typo3/ext. So you see the 
logic in this area is already historically more complex. I see your 
intention of simplifying logic here, but it restricts also your 
flexibility and this is the heart of the CMS.

>
> 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

Christian already told why the error supressing and include is bad. The 
Flow Team already tried that in their performance sprint and quickly got 
back to the file_exists require combination.

> 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.

Those folks are currently unfortunately everyone using any extension 
like news, flux, gridelements and so on. This means it will have hardly 
any impact.

> 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.

So the first thing is this change is nothing we can do for 6.2 now. 
According to our deprecation strategy we can announce that now and 
remove it in 6.2+2. This means at the earliest by end of 2014 or mid 
2015, depending on the release schedule.

Second is that we're talking about an improvement in just the class 
loading area in a fully cached frontend request. Class loading takes in 
sum about 30.5% inclusive wall time of the request. The pure logic 
excluding the actual loading/parsing/processing time of the class file 
takes about 17% of that area. This means were talking about improvements 
in 5,185% of a request. Following these numbers an improvement by 20% of 
the actual class loading logic will result in about 1% improvement of 
the whole request. This will be already captured by the class loader 
backend improvement I anounced.

> What do you think?

So what do I think? I think your suggestions don't target the topic of 
this thread "Taming the Performance in 6.2" regarding the breaking 
changes. Further it involves isolating CMS in the PHP ecosystem again by 
creating custom interpretations of standards. And lastly I think that 
most suggestions I have seen leave out requirements.

Greetz

-- 
Thomas Maroschik
TYPO3 CMS Active Contributor

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