[TYPO3-dev] Are performance improvements part of maintaince releases?

[Michael Stucki]

Hi Rupi,

thanks for moving this topic away from the core list. On the other hand, 
I'm not quite sure if typo3-dev does really fit better for answering 
such a question. See below...

> again:
> Are performance improvements part of maintaince releases?
> 
> or in other words: 
> is a function that makes 50 identical sql requests when rendering a page a
> bug?
> 
> the last discussions about this questions in the core list showed that we
> don't have a consensus on this issue.

Agreed. Let's first find out who is "we"!

I see that TYPO3 has two different groups of users:

1) Users who want a perfect CMS on their website
2) Users who need a reliable CMS on their website

While the first group is probably pretty wide-spread over this mailing 
list, the other one most likely is completely missing.

That means that we can only guess if the majority of users (commercial 
companies) want to avoid any risks and just want a reliable system.
However, being in touch with many different clients all day out, I would 
say that they build the majority.

> Current cases:
> http://lists.netfielders.de/pipermail/typo3-team-core/2009-June/027147.html
> http://bugs.typo3.org/view.php?id=11358
> 
> http://lists.netfielders.de/pipermail/typo3-team-core/2009-June/027185.html
> http://bugs.typo3.org/view.php?id=11317

Just to point that out: If these improvements were plain simple, I would 
have no objections against adding them, because as you already pointed 
out, it is well possible to define them as bugs.

However, in both cases we cannot say for sure that they won't introduce 
new problems (see below). Because of this, I would like to stick to the 
principle: "when in doubt, better don't touch it".

And in case you're not aware of it: In the past we have also kept 
distinct bugfixes away from the stable branch because their solutions 
were too complicated.

> the reasons for reverting 11358 and for preventing 11317 from being applied
> to the 4_2 branch are:
> (wildly citing from these 2 threads)
> - "performance tuning is not part of maintainance releases."
> - "There is no urgent need to improve the performance. It's just nice to
> have."
> - "the risk to break something is always higher than without a patch"
> - "...I think we had some problems earlier with similar kinds of caches,
> which produced unexpected results in some scenarios..."

I still think these are valid points.

> OK, we have a release-workflow document but it doesn't say anything about
> performance improvements:
> http://typo3.org/teams/core/resources/release-workflow/

It seems like that document is not precise enough, granted. I'm open for 
suggestions in regard to this.

In any case: We should not talk about any "rules" here but rather about 
what is most wanted by the users. If a rule turns out to be based on 
wrong assumptions, it should be improved rather than being used to 
enforce the bad practices.

> so argument 1 seems to be pointless. or I have overlooked something?
> 
> next point states that performance improvements are only a "nice-to-have"
> thingy. Hmm, ok, matter of taste for some people, maybe. But what about the
> people for them performance is a bit more crucial thing? holding back
> performance related fixes in maintaince versions seems to ignore them and
> their needs.

I count myself to this group as well, and I guess that you well know 
that. However, both examples from above are not so easy to check. At 
least you cannot be 100% sure nothing gets broken because of the new 
behaviour.

For those people who need performance improvements under all 
circumstances, I propose to use a patched version (just as you did for 
your measurings).

By the way, at my work I'm also using such a patched version for some 
sites (not globally but just where it is urgently needed). It contains 
the backported treelist cache, and some other backports...

> and point 3 and 4 say that adding a patch could possibly break something.
> uhmmm, yes that's true, indeed. We are humans and humans make mistakes
> (remember 4.2.4). But is not adding obvious improvements a solution for
> this problem?
> 
> Dudes, are we core-devs or are we sissies?! ;-)

I'm not at all happy about the issues that were introduced by 4.2.4. 
Unfortunately, the loss of trust weights much more than any of those 
little improvements no matter how nice it was. Think about it.

> We know what we are doing. 
> We are able to say that adding a few lines of code that prevent a function
> from bothering the database with 50 identical queries will NOT break
> anything. We only have to read and test the code. 

Just to give you some examples why I think that even the most simple 
code brings some potential danger with it:

Did you verify that
- no updates have been made to the database in-between?
- no versioning or translation layer has been initialized?
- etc.

Can you be 100% sure about it? I can't.

> And we're also able to say that enhancing TYPO3 4.2.x by a cache for an
> expensive function which has been tested for almost a year now in TYPO3 4.3
> will not break anything.

The same can be said for
- OpenID integration
- RSA authentication
- caching framework
- and many more ...

These are all nice features and they work pretty well in TYPO3 4.3, 
however we won't backport them for 4.2. These features have been 
implemented for TYPO3 4.3 and as soon as it is released, everyone can 
take advantage of them.

Finally, I wonder if the overhead of maintaining multiple branches at 
the same time is needed at all, if every of these features could be so 
extremely useful for the version which currently marked "stable" 
(stable, what?) From this point of view, one Trunk with releases every 
1-2 months would be much better.

However then: Why is nobody using 4.3alpha on their website?

> and while we are on it: 
> let's also talk about other improvements in current (stable) versions. what
> about this:
>  
> 2009-06-02  Steffen Kamper  <info at sk-typo3.de>
>         * reverted #9849 as this wasn't present in 4.2.0
>         * Fixed bug #9849: edit-wideDocument was removed, bring it back
> (from 4_2 branche changelog)
> 
> dropping "edit-wideDocument" was a bug! no question !
> Will there be no chance to fix usability errors once the xx.0 version is
> out?

The thinking behind it is that content editors are trained for each main 
version (4.1, 4.2, etc.) but never for patchlevel updates. Therefore, 
the user interface should not change within such a branch.

> PS: at the end of this discussion I'd like to see a document which clarifies
> which improvements are bugs and which are not.

Agreed. I'm open for suggestions, but please find a consensus first.

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