[TYPO3-v4] Minutes from the 28th meeting of the release 4.5 team

[Steffen Gebert]

Hi,

thanks for the minutes!

> -----------------------------------------------------------------------
> Performance issues
> -----------------------------------------------------------------------
> T3 Compressor
> -----------------------------
>
> Analysing with kCacheGrind seems to point to t3lib_compressor as a main
> performance brake (10%). Apparently doing serialize / unserialize
> operations. Ernesto mentioned that the t3_compressor doesn't do any
> serialization (it "just" gets md5 hashes from files and compares...) so
> this would require further analysis to get solved.

As stated correctly, t3lib_compressor builds up an array of the 
filemtime, filesize and path
* in case of merging (CSS): of all affected files
* in case of compressing: only of this particular file.

This array is then serialized and md5-hashed to ensure uniqueness of the 
target merged/compressed file (something changed -> new file).

The amount of files is 130<x<180 I assume (~110 CSS files plus lots of JS).

I know that it, of course, costs some cycles, however I don't expect it 
to be that complex. Nevertheless, I'm happy to get profiling data and 
suggestions, how to improve. If it's really the serialize, maybe there's 
another way to create some identifier out of an array.

As Christian already told me that he wants to make more intense use of 
the Caching Framework on 4.6, I think we could really put this 
computation in some cache. At the point of writing (for 4.4) there was 
nothing except the Configuration Cache, to which it could have been bound.

I'm a bit sceptical with the "adding to 4.5.x" topic. IMHO TYPO3's 
advantage is to be solid and easy to upgrade (except few regressions, 
mostly due to security fixes in the last time).
If things can be identified, which really cost enormous time (like 10%), 
I'm fine with considering it as a bug and fixing it in patch-level releases.
For other things - and the CSRF goes into that direction (as mistakes 
can break things) - I tend to say "it's out as it is" and only fix real 
bugs. Of course, security matters, and leaving one single hole open 
contradicts with the principle of CSRF prevention in the Backend, but I 
really fear to break a place, which was forgotten/not tested/used in a 
customized way. People don't expect patch-level releases to break things 
(I hope ;-)).

I agree with Steffen's need for some relaxation (for him and for me/us 
all ;)).

Kind regards
Steffen

-- 
Steffen Gebert
TYPO3 Core Team Member

Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/