I recently did a performance analysis of a TYPO3 installation. Just from looking at the code it could not spot any major performance problems so I dug out the big guns and had a look at the code with xhprof.
As a five year TYPO3 extension developer who has seen quite a few things I was really surprised to find two significant things that I have not known about before.
1. Use PaginateViewHelper with caution
Fluid has a little known secret:
When using Fluid's PaginateViewHelper the template won't be cached.
In TYPO3 6.2 these ViewHelpers are affected
Not using those ViewHelpers is probably not an option, but you can try keeping the templates that contain these as short as possible. Using partials helps a lot here:
By just refactoring the Fluid templates with that in mind, we could speed up the rendering of a list view by 22% and save an additional 10MB of RAM per request.
If you want to dig deeper into the issue (or you just don't believe me ;) ), have a look at Fluid's
TemplateParser. Ideally the
parse()method should not be called on production (except on an empty cache). If you have some profiler running, check that this method is not causing you trouble. The code that disables the cache is in
initializeViewHelperAndAddItToStack(), more specifically when setting
2. Utilize the autoloaderIt might sound insignificant, but you really should make sure to use the autoloader. In one project we could improve the frontend speed by almost 5% by teaching a legacy extension to use the autoloader.
Most legacy code has something like this in their code
As long as this string is only parsed once this is nothing you need to worry about, but do it a few hundred or even a thousand times in one request and you are in trouble. When parsing the path and class name most time is spend in
GeneralUtility::getFileAbsFileName. The extension key needs to be separated from the rest of the path, it must be checked if such an extension is enabled, and the path to the file needs to be determined. Ugh... lots of work... only to find out that the file was already included.
In the above code example the "getRecordOverlay" hook is used that is basically called everytime a record is fetched from the database. Depending on the complexity of the page this might be easily called a few hundred or thousand times while rendering a frontend page.
When using TYPO3's autoloader functionality the autoloader will only kick in the first time a class is required. Successive calls won't have any negative performance impact at all. And as a bonus you get code that is cleaner and easier to read.
There are lots of things one can do wrong when writing code. Most of those things don't have a measurable impact on performance, but some might turn out critical.
What are your tips to improve performance of TYPO3 Extensions?