[TYPO3-dev] Discuss - RFC #11474: Store separate extlist for the frontend

[Mathias Schreiber [wmdb >]]

I just want to share my point of view:
Performance matters to me, since it is vital (!) to several larger 
projects of my business.

This fix is rather simple.
Exclude what you don't need.
As a result of the performance meeting we stated that removing 
EVERYTHING we don't need takes hell of a lot of work (and believe me, 
there are TONS of things you don't want in your frontend - just debug 
$GLOBALS, set up coffee and spend an hour or two in it and for every bit 
of code or config you don't need in ANY request, slap yourself once... 
enjoy :))

This is why we focused on improving things "step by step".

But instead of arguing if the name of a switch is smart or not it would 
be helpful to check if the patch works, since Rupi (thanks at that point 
btw) attached some numbers.
Besides:
I'd LOVE to see this by more core-devs after they introduce features, 
this would make the life of the inofficial performance team MUCH easier 
and WAY more fun.

Regarding those "modes":
Somebody has to enlighten me, but I don't know of ONE extension that 
works purely in the frontend (except someone just set's up a lib to 
include it on any page and if he uses an extension with all it's 
overhead he'd to be punished (HARD) anyways).

Bottomline:
Mode FE - covered by the patch
Mode BE - enlightment needed
Mode CLI - um... when would you launch 30 concurrent CLIs?

On performance in general:
With all this convention over configuration stuff we gain development speed.
Since NOTHING in life is free, this speed has to be lost somewhere else 
(global principle... matter exists).
So obviously we introduce a lot of overhead at some point.

And if you do so, double.. no... tripple check your code for speed, 
improve ANY loop, every variable and so on.

Now for the discusion part.
I know we all want to make TYPO3 better - I really do.
But it would be helpful to everyone involved if we could make quick, 
simple, "performant" decisions.

I'm am really sure, this patch can be re-done to make it even faster.
By making t3lib_div smaller (did you ever measure how much time your 
machine spends including this class?), or by keeping $GLOBALS smaller or 
whatever.

But finding out what happens when you simply remove this and remote that 
takes time.

So we focused on small changed, simple things with "near-to-none" impact.
But instead of "talking" the 100% solution, maybe "commit" the 80% 
solution so everyone participates from it.

*getting ready to get bashed, but has a fridge full of beer so go ahead :)*

Mathias

-- 
TYPO3 certified interogator
T3DD09 Entertainer