[TYPO3-core] Taming the Performance in 6.2

[Mathias Schreiber]

Quote: Thomas Maroschik (tmaroschik) wrote on Thu, 07 November 2013 13:09
----------------------------------------------------

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

We are talking http://www.php-fig.org, right?
See, my intention is to "bend" the part we have control of.
That would be typo3/sysext (I stick to old names, because it makes things easier to grasp).
Everything else would reside in one folder, like PSR-0 suggests.

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

You mean the principle of XCLASSES?
My idea was to register "XCLASSES" at a central place like we do today.
My personal opinion is that if you need to use XLCASSES, you're doing something horribly wrong.

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

I agree on the error supression part.
We should get rid of that in the current autoloader too, then btw.
Regarding the include part.
Well... if you have buggy code how would that not affect require?
I don't see a usecase for that right now, could you please elaborate?

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

Agreed.
The impact will be small today.
But the more extensions change to "clean code" (is it ok to stick to that term?) the better it gets.

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

I do realize this policy exists, though I kindly ask if it can be re-thought because customers will expect excellence from a LTS version.
The current speed is not acceptable.
 
> 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.

You math is partly correct.
It will impact 1% of the CURRENT request.
Since our indepentent benchmarks on 3 different, isolated machines show a decrease of 800% in average the impact yould be 8%.
The slower the filesystem, the greater the benefit.

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

I see I didn't write my "XCLASSING" concept in the first post but it seemed rather obvious and simple to tackle to me.
A great start would be some sort of list of things we definetely want to keep and things that might be changed.
This way my performance concepts can come to life faster.

See, all I try to do here is help by looking at things from the most simple way.
So if we could get a fruitful discussion in the style of "yeah, this might not work out but we could do this and that" we would get more things done in the same time.