[TYPO3-project-4-3] 4.3.0 vs. 4.2.7

[Rupert Germann]

hi Joey

JoH asenau wrote:
> There is one sentence that might be a hint for the concept of the CF:
> As the focus is on high performance, the data is _not_ serialized or
> processed in any way.

and another quite important statement from
the "how-to-boost-speed-up-your-typo3-website-with-nginx" article is 
"All of the above solutions, with the exception of nc_staticfilecache, have
one thing in common: in order to read cache, one has to invoke a php
process, read and parse the cached data, and then send the information to
the browser."

btw: thanks Bartosz for this great articles!

I seems to me that we should think about dividing the functionality of the
CF to at least 2 parts: page cache and application caches.
page caching should prevent starting any unneeded line of code.
application caching (cache_hash,pagesection,treelist ...) can use a more
flexible structure because once it is needed, the whole TYPO3 machine is
running anyway. And then it is indeed very helpful to get a treelist which
needed 1000s of queries to build it directly from APC without wasting mysql
bandwith.

some numbers:
4.2.7 renders a page from cache in 11ms
4.3.0 needs 14ms for the same task

when rendering this page there's no harddisk activitiy in both systems, all
php files are delivered from eaccelerator cache and the mysql result comes
from querycache, too. 
So what I mesure here is pure php performance. It's obviously where this
addtitional 30% are wasted.
the 11ms from 4.2.7 are result of a rather optimized directly coded db
caching. I doubt that it is possible to beat this number by instantiating a
complex framework. 

So what can we do about this?
as said before, the CF is quite useful once the whole TYPO3 machine is
running anyways. But for the case where we only have to deliver already
cached content as fast as possible another approch is needed.
 
>....
> After all caching (framework or not) is about performance and not about 
> implementing fancy programming patterns.

+100 and full ACK
 
> Why does the CF use exec_SELECTgetRows for the "db backend", if there will
> be just one entry per identifier anyway?
> What about checking for MySQL COUNT being TRUE instead of fetching a whole
> dataset and counting it's entries with PHP to check for the existence of
> an entry?

it was (and is) partially even worser:
http://bugs.typo3.org/view.php?id=11288
http://bugs.typo3.org/view.php?id=11286
http://bugs.typo3.org/view.php?id=11285

and my personal favorite:
http://bugs.typo3.org/view.php?id=11175
;-)

greets
rupert