Currently the physics engine takes up a lot of the servers tick time.
On my server, for example with 3 trains running cam72cam.immersiverailroading.entity.physics.SimulationState.next() takes up 41% of the total server main threads time.
78% of ticktime within SimulationState.next() is taken up by cam72cam.immersiverailroading.tile.TileRailBase.getNextPosition().

getNextPosition has a complex while loop that is executed every phyics tick.
This could potentially be re-written to only be calculate once on loading/placing and then cache next positions for given headings and switch states.

sampler-snapshot.zip

It's build from #1362.
Event with only 1 Train (1 Locomotive, 3 Wagons) going at 200km/h the server tick time increases from 30ms to 50ms.
In the snapshot had an additional train running with 2 Locos, 8 wagons at. 160km/h.

Do you have any ideas how to improve this?
One possibility might be to calculate and save centre paths in the rail tiles (with branches for switches).
Then it would be possible to give the path a distance and get a position without much calculation.
Then the path only needs to be calculated once or when connected nodes change.

Storing such a path might also allow for potential built in automation in the future.

A few questions:
Which build?
How many pieces of stock and at what speed?

getNextPosition is complicated by a few concerns:

1. Overlapping pieces of track
2. Switches (similar to 1)

Depending on location and direction, the output vector can be dramatically different.

The paths are already cached, it's figuring out where along the path / which path that takes the time.

200km/h in minecraft requires a significant amount of computation, not just by IR. While it is supported, moving at that speed is definitely tricky.

I've recently merged in changes that dramatically reduce the overhead of moving trains on a server. I am going to close this issue.