Slow Expression in AE 2018 (BUG?)

The problem is that your procedure of breaking a text layer into an array and then splitting it to use only one of the values is nonsense. It quadruples the number of calculations that must be done to get a number and because of the recursive nature of the expression, the larger the slowdown. The faster comp is still recursive, it is just no slowed down by 4X.

Both compositions in my version of AE start out quickly and then slow way down until everything is cached. Clear the cache on 2017 and 2018 and there is hardly any difference on my machine. Both have cached and playing back in less than 30 seconds. The slow comp may take about 4 or 5 seconds longer, but that is because your approach to controlling speed is not as efficient as it should be.

If you want to control a single value with a text layer then there is no need to create and split an array. It's a waste of calculations. If you are going to use time in your calculations then put the time calculation in the array or declare it as a variable in the same property.

The way you have approached the problem is

1. create an array with the first value zero, then
2. calculate the second value by figuring out what the current time value is then rounding the time value and then multiply the result by 600
3. take a look at the text layer causing to see what is going on there
4. there is an array so split the array and only use the second part
5. find out what is going on in the second part of the array by running the calculations again
6. add that value to the current y position value then repeat step 1 through 5

A less recursive approach would be to

1. assign the current time to the text layer
2. build a position array using the current position of x for the first part and add the text from the text layer to the y value
3. multiply the y value by 600 and repeat the first two steps for the next frame

There is no need to round the time value because you have done nothing in your calculations to accurately position the layers on the pixel grid. That would have been a good idea. Typing a value in the text layer does nothing to change the speed of the y movement so using a text layer for the time value is completely useless. You would need some kind of value + statement to make retrieving time values from a text layer more valuable than just using time in the position expression.

So what is wrong here? The entire approach to the problem of moving and repeating the movement of layers based on the value of time in a text layer. The way you have approached the problem forces at least five recalculations on each frame all of them going back to the first frame of the comp. Simply adding time to the position array and doing a little multiplication changes the number of calculations to 2, how far back is the start of the composition and multiply.

Show me a setup that will change behavior if you change the text entered in that layer instead of manually editing the expression and I'll take a look. There may be a small difference between CC2017 and CC2018 in the way my system and OS handles the calculations but the difference is negligible. In fact, if I just open the project in both applications and don't play with anything for 30 seconds all comps play in real time because I have cache in the background running. The only slowdown I perceive is when I purge everything and immediately run a preview. Then the first few frames playback in real time and then the slow down starts. The expected performance does not show nearly the slowdown when processing because it does not go through the loop. If I simply use the text layer for time and do the calculations directly in the position array the caching time is so close to the expected behavior comp that I can't tell the difference.

Is there a bug or a performance hit in CC 2018 on my machine using your method? Performance hit, yes, bug, I'm not sure. I reopened the project in both and used a stopwatch to test the slow comp render preview speed, CC 2018 > 14.4 seconds, CC 2017 > 13.7 seconds. Scrubbing the timeline before the ram preview was rendered showed no noticeable differences. Changing the expression to only delivering time, not an array and keeping the math round but doing all of the calculations in the position property - CC 2018 > 9.4 seconds, CC 2017 > 10.1 seconds. Some human error with the stopwatch is possible. Removing the mathRound operation cut the time by more than 2 seconds in both apps and made no measurable difference in the position values of the layers when checking the same frame so that part of your method is a waste of time.

If you want to share the exact method you are having problems with I can try and diagnose the problem but there isf nothing in your sample project that could not be done easier and faster using another method.

I have an animation preset that comes in two parts. The first part creates a hand full of animation sliders and checkboxes. The second part uses the layer's in point, out point, size, scale, and builds an array that will take into account the scaled size of the original layers and / or automatically scale them to fit in a grid defined by the controller layer, then move them an exact whole pixel value horizontally, vertically or diagonally across the screen and there is nothing recursive about it. It does not use time. 4 layers or 100 or 1000, it doesn't matter. I would use that to create your example video. Create one solid that is 50 X 50 pixels, add a null and apply the controller preset, determine the number of columns, let the rows take care of themselves, apply the second part of the preset to the solid, then duplicate the layer as many times as needed to fill the array, keyframe the movement and check the repeat box and indicate the number of frames before the repeat. There are also check boxes that fly the layers in one from the top, bottom, left, or right based on layer in points or fly them out based on the outpoints. That may be what you have created but are uinwilling to share. The proejct you shared is only a good example of how not to drive animation using time.