TYPO3 Core

.. and also 14% of page module rendering

is this just a problem of quality or quantity?

In other words: Is the code too slow or are there too many superfluous calls?

I don't know, if we could save calls. It's called 20 times in the attached example call, which consume too much time every call.

Attached patch changes the most obvious things.

It removes preg_replace where it was not necessary.
It replaces strstr with strpos.
It removes a for each loop in favor of array_diff and array_intersect_key.

Attached V2 that adds a missing array_unique to remove doubles from the insertionArray as well.

Did someone actually measure if array functions are faster? Helmut showed me today that a foreach is sometimes faster.

Instead of the if-with-strpos maybe rtrim($item, '0123456789') will be faster?

BTW Regular expressions are often surprisingly fast (highly optimized library)

@Jigal van Hemert: We won't know if it's faster until we will test different functions in the same context.

Currently I haven't got a testing environment available, but I guess Steffen can tell us if the changes had any impact compared to his first results.

Depending on the context foreach might be faster than some of the array functions but usually this is only true for large arrays, which we don't use in this function.

At least intersect_key should be quite fast, since it will work on keys and therefor can use stuff which is already optimized by PHP.

We could change array_unique(blah) to array_flip(array_flip(blah)) and of course there are lots of other options we could try to optimize it.

This is why I didn't post an RFC yet. So we can try to find the best solution for our use case first and maybe later on we can port it to other places in the core that are using similar approaches.

Regarding the regExp I would say that they are currently used in the right place, namely to split up both the insertionList and the current list into a multidimensional array, which is always significantly faster than a nested foreach loop.

The question is, if we really need this kind of array at all or if it might be possible to tackle the whole task with regExp (preg_replace) only.

Attached another version with optimized order of conditions in if clauses and

if ($item{0} == '-') {
$item = rtrim($item, '0123456789');
}

as a strpos replacement.

v4 was buggy use v5 instead

Using Xdebug and WinCacheGrind I found out that the original removeDuplicatesForInsertion was much faster than the one with the array functions - BUT: the rest was significantly faster

So a combination of the last patch with the original removeDuplicatesForInsertion runs up to 4 times faster than the original addToAllTCAtypes.

Attached is v6 that currently seems to be the fastest

ACK. I profiled v6 against original code:

file           original      v6        v6/orig
------------------------------------------
backend.php    11,74%     5,69%    48,47%
ajax.php       25,80%    14,44%    55,97%
ajax.php       23,48%    11,52%    49,06%
ajax.php       29,15%    13,04%    44,73%
ajax.php       25,21%    19,93%    79,06%
ajax.php       26,86%    11,58%    43,11%
ajax.php       29,99%    18,88%    62,95%
alt_intro.php  13,90%     5,06%    36,40%
ajax.php       32,27%    32,08%    99,41%
alt_intro.php  14,07%     6,50%    46,20%
ajax.php        3,75%    16,43%    48,68%

The table shows the percentage spent for addToAllTCAtypes during one backend call

Pending in core list