[TYPO3-core] Taming the Performance in 6.2
tmaroschik at dfau.de
Thu Nov 7 08:26:18 CET 2013
Am 06.11.13 15:40, schrieb Mathias Schreiber:
> Dropping PSR-0 support is no option?
> Imagine this:
> 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.
> 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.
TYPO3 CMS Active Contributor
TYPO3 .... inspiring people to share!
Get involved: typo3.org
More information about the TYPO3-team-core