[TYPO3-core] Taming the Performance in 6.2

[Thomas Maroschik]

H Mathias,

Am 06.11.13 15:40, schrieb Mathias Schreiber:
> Dropping PSR-0 support is no option?
> Imagine this:
> typo3conf/ext/VENDOR/extensionA
> typo3conf/ext/VENDOR/extensionB
>
> So instead of punishing everyone working "correctly" with his namespaces
> with bogging down the system we could just set up a rule like "Your
> namespace has to be equal to your directory structure".
> If it is not, well... bad luck.

Well this is a decision we have to take. Do we want to align ourself to 
the rest of the currently evolving PHP ecosystem including Flow or not? 
Do we want to constrain the length of the vendor part? Personally I'm in 
favor of keeping it.

> Option B:
> Have an extension register its rootpath once and keep these in memory.
> So if you use \Husel\Blablupp\MyClass() it has to reside in
> Classes/Blablupp/MyClass.php in the extension dir that registered \Husel

This is already done. The PackageManager figures out what the rootpath 
of the package is and keeps it in memory. It resolves exactly the way 
you described the class path then. As the vendor/extension part of the 
namespace is of variable length you still need the check I described in 
my last post.

> This could drastically reduce the amount of disk I/O.

It does that by skipping the proxy require. This means at best 2 FS 
calls skipped. First one for the file_exists and the second the 
require_once of the proxy. The latter is maybe even fully cached by your 
opcode cache and access to it is faster than a symlink then.

> @Tom:
> Could you post your measurements about the differences on "keep stuff in
> RAM" vs. "access a lot of files"?

I did not keep the profiling data from the last year where I started 
what ended up here in the core.

 > There has to be a certain breakpoint where accessing lots of file
 > out-race the RAM usage.

Keep in mind that PHP cannot keep anything in RAM from request to 
request. It has to be loaded upfront from disk to ram during the 
bootstrapping process and introduces its own delay. Parsing that large 
arrays and building them is expensive too. Still the issue with that is 
that the information is needed exactly just once per entry.

As already mentioned I'm currently exploring if the solution I proposed 
in my last message works out. Don't judge it yet. If it's ready to test 
feel free to make an A/B test.

Greetz

-- 
Thomas Maroschik
TYPO3 CMS Active Contributor

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