Speed! - Why most lighter things are faster

By: Mathias Schreiber

The first performance meeting was a success - this is what the participants try to achieve:

Some weeks ago I called Rupi (Germann) and Joey (Hasenau) and asked whether they were interested in spending a weekend on checking TYPO3's code for performance problems and to go wakeboarding with Rupi's boat.

Later Michael Stucki joined in because in our eyes he's the boss of 4.x development anyways and it would be nice to meet again, since we only see each other on the regular events.

Joey and I arrived on friday and spent the night with tracing performance problems through the frontend while having Ben on Skype in order to find some more diplomatic ways to write down our results.

Stucki arrived on saturday morning and after breakfast we sat down and checked what else can be done.

We identified three major parts that drew our attention:

• Reducing unneeded database queries
• Reducing loading overhead
• Reducing the amount of small checks throughout the core

We used Rupi's testing environment for all patches and ran all tests several times so we could get clean numbers on how these patches affected the performance of the current 4.3 trunk.

Some fun facts:

• Including classes takes an tremendous amount of time (more than 20% of the full request time)
• Only 3% of this information is actually needed
• TYPO3 loads very much information at every request although it isn't needed
• after including our patches we came up with a 33% increase in speed (for cached pages though)

Some of our patches are pending in the core list right now and we hope to get them included in 4.3.0, so heavy testing is highly appreciated.

Outlook:

These are the things we plan to do within the next few meetings:

• Introduce t3lib_essentials (a rip-off of t3lib_div) that brings only the most neccessary functions to deliver cached pages
• Load only the most neccessary config needed in the frontend (only parts of the TCA etc.)
• Reduce the number of duplicate database calls to zero (if only... :))
• Massively reduce the size of $GLOBALS
• Stay backwards compatible - which is quite tough
• Check things once
• Supply performance related documentation (maybe even CGL)
• Supply a testsite that features:
  • Typoscript
  • Cached and uncached pages
  • Transparent user logins
• Supply documentation on:
  • Setting up a testing server
  • Setting up siege
  • Setting up xdebug and kcachegrind
  • Explaining how to read cachegrind (since it looks like some 1971 LSD trip when you first look at it)
  • Explaning how to read numbers
• Make developers aware that performance DOES matter

As with most things in open-source development 4 people are only a start - help is highly appreaciated and actually, it is much easier to help than you might think.
So no matter if you are a designer, doing Typoscript all day, an extension developer or a member of the core team... jump in, help out!

cheers
Mathias

---