[TYPO3-core] TCA, ext_tables.php and caching concept

[Dmitry Dulepov]

Hi!

Oliver Hader wrote:
> Well, it does, as well as explaining the accordant steps. Basically it's
> "We realised the TCA handling must be improved to gain speed and to make
> things easier for developers at the same time." which also means to have
> a transparent layer for TCA, have the procedure as part of the bootstrap
> mechanism and also ease the cross-linked runtime behaviour for
> developers that don't now much about those internals and just want to
> concentrate on build the application layer.

$TCA is a BE mode thing. It was never fully available in FE. It was made 
available now at a cost of speed and memory consumption. Neither 
Christian's message, nor what you write, justifies slowing down or 
increased memory consumption. May be developers will use $TCA now. Or may 
be not. But TYPO3 is slower and more memory hungry already. Was it worth?

> So besides "because we can" there are some valid aspects making this
> change acceptable.

I still fail to see them.

>
>> >  - why would you slow down TYPO3 first and fight next to bring the same
>> >  speed back?
>
> Interative steps in refactoring are not bad instead of trying to solve
> everything at one time. Besides that smaller chunks can be reviewed and
> understood better...

Theory again :(

Can't those steps be done outside of the main product to implement, test, 
profile, fine tune?

> FAL was a project that aimed to have the full featured solution
> available in an external repository. In the end it turned out, that
> merging and keeping track of the in-between changes in the Core made it
> just more complicated to get things back. Iterations of working code in
> the Core would have been much better in that regard. It's not exactly
> the same with TCA, but comparable.

FAL is justified because it opens possibilities to use Amazon or other 
cloud services. This $TCA patch does not show any such advantages. Or I 
still fail to see them.

Btw, FAL performance with thousands of files can be easily improved by 
several simple database indexes...

> Or in other words:
>
> ∑(i=0;∞) 1/2^i = 1/2 + 1/4 + 1/8 + 1/16 + 1/32 + 1/64 + 1/128 + ...

Yeah, I saw that when I was a student about 17 years ago. Never used this 
stuff since that time :)

> Which then just turns out to be "2" in the end. So, first reducing the
> complexity, work with the result and see that the result can actually be
> written much easier in the end.

To me the rule is different: "commit it, if you are sure that it makes 
nothing worse".

>> >  - why do you think the performance will improve?
>
> What makes you think it won't improve at all?

This reminds me "Atlas shrugged" a lot :)

Because:
- it is very easy to make performance worse but it is very hard to improve it
- TYPO3 performance always became worse in the past years
- if it was not done in time, most likely it will never be done

-- 
Dmitry Dulepov
TYPO3 CMS core & security teams member

<strike>Simplicity</strike> Crocodiles will save the world.