Rail updates are 4-5x times laggier since 1.14 if the rail is on top of a non-full cube

Powering and depowering rails that are on top of non-full cubes is 4 to 5 times laggier since 1.14 than 1.12.2 and below

"The primary bottleneck lies in shape comparison which is performed to determine whether the block beneath the rail is solid on top and can support it." - JellySquid

• 1.12.2 used a simple boolean check

• 1.13.X ¯_(ツ)_/¯

• 1.14-20w18a recalculates the hitbox of the block below the rail every time

• 20w19a-20w27a uses a simple boolean check for full cubes which decreased lag massively but still recalculates the collision box of non-fullCubes every time

• 20w28a+ Caches if the rail can stay atop the non-fullCube

Below are some testing results.

I have a void world with 10,000 rails atop top-slabs running on a 2gt observer clock
5000 rails update every gametick (half those turning on, half turning off)
16 chunk render distance, 2gb of ram for the JVM

The world ran at less than half an mspt when idle which was consistent across all versions.
Each test was done a few times to get stable results.

Lithium heavily optimizes the shape comparison check:

1. Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)

2. Cache if the side of the block can support the rail (slabs)

World Download: