MC-182868Rail 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.
| Version | Client | TPS | MSPT | Thumbnail |
|---|---|---|---|---|
| 1.12.2 | Vanilla | 24.69 | 40.5 |  |
| 1.13.0 | Vanilla | 12.23 | 81.75 |  |
| 1.13.2 | Vanilla | >20 | <50 |  |
| 1.14.4 | Vanilla | 5.55 | 180 |  |
| 1.15.2 | Vanilla | 5.37 | 186 |  |
| 1.15.2 | Lithium | 28.57 | 35 |  |
| 20w18a | Vanilla | 4.85 | 206 |  |
| 20w19a | Vanilla | 5.46 | 183 |  |
| 20w19a | Lithium | 30.3 | 33 |  |
| 20w28a | Vanilla | 30.3 | 33 |  |
Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
Linked Issues
Attachments11
Created Issue:
Updating Rails atop non-FullCubes are 4-5x times laggier since 1.14
Powering and depowering rails that are sitting atop non-FullCubes are 4 to 5 times laggier since 1.14+ than 1.12.2-
"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 uses a simple boolean check for full cubes which decreased lag massively
But still recalculates the collision box of non-fullCubes every timeBelow 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
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 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: Rail Slab Update Lag 1.12.zip
Attachments10
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Updating Rails atop non-FullCubes are 4-5x times laggier since 1.14Rail 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
sitting atop non-FullCubesare4 to 5 times laggier since 1.14+than 1.12.2-"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 uses a simple boolean check for full cubes which decreased lag massivelyBut still recalculates the collision box of non-fullCubes every timeBelow 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 JVMThe 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
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 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: Rail Slab Update Lag 1.12.zip
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 uses a simple boolean check for full cubes which decreased lag massively, but still recalculates the collision box of non-fullCubes every time
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 JVMThe 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.
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
![[Mojang] Matthew Gatland](../../../data/avatars/users/43046.png){kind=small}
[Mojang] Matthew Gatland![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
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 uses a simple boolean check for full cubes which decreased lag massively, but still recalculates the collision box of non-fullCubes every time
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 JVMThe 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.
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
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 uses a simple boolean check for full cubes which decreased lag massively, but still recalculates the collision box of non-fullCubes every time
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 JVMThe 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.
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 20w28a Vanilla 30.3 33 Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
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 uses a simple boolean check for full cubes which decreased lag massively
,but still recalculates the collision box of non-fullCubes every timeBelow 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 JVMThe 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.
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 20w28a Vanilla 30.3 33 Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
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 JVMThe 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.
Version Client TPS MSPT Thumbnail 1.12.2 Vanilla 24.69 40.5 1.13.0 Vanilla 12.23 81.75 1.13.2 Vanilla >20 <50 1.14.4 Vanilla 5.55 180 1.15.2 Vanilla 5.37 186 1.15.2 Lithium 28.57 35 20w18a Vanilla 4.85 206 20w19a Vanilla 5.46 183 20w19a Lithium 30.3 33 20w28a Vanilla 30.3 33 Lithium heavily optimizes the shape comparison check:
- Simple full-cube check with early exit (which was added in 20w19a to decrease lag from rails only atop full cubes)
- Cache if the side of the block can support the rail (slabs)
World Download: Rail Slab Update Lag 1.12.zip
Relates to
MC-174568Can confirm 1.16 pre release 4
in 1.16RC1
Can confirm for 1.16.1
Can confirm for 20w27a
fixed
RedCMD thank you for the test world and benchmarks!