Environment
Sable version: 1.2.2
Minecraft: 1.21.1
Loader: NeoForge 21.1.243
OS: Ubuntu 24.04.4 LTS (amd64), kernel 6.8.0-106-generic
CPU: AMD EPYC (12 threads available)
Java: 21.0.11, OpenJDK 64-Bit Server VM
Related mods installed: Create Aeronautics, sablecompanion, sable_sa_compat, create_mekanism_compat, Shtreimel (diagnostic tool)
Description
On a freshly generated world with no player-built ships, platforms, or sub-level structures whatsoever, Sable consistently accounts for ~13-16% of total server tick time across multiple profiling sessions. The cost appears constant regardless of world content, which suggests the physics pipeline is stepping every tick unconditionally rather than only when active sub-levels exist.
Profiling data (via spark)
Server thread total: ~113ms/tick average in one session (target is 50ms for 20 TPS)
Sable's call stack breakdown (Merge mode, Percentage label):
sable (v1.2.2) — 15.76% of server thread
├─ ServerSubLevelContainer.tick() — 10.40%
│ └─ SubLevelContainer.tick() — 10.58%
│ └─ SubLevelPhysicsSystem.tick() — 10.25%
│ └─ SubLevelPhysicsSystem.tickPipelinePhysics() — 10.22%
│ └─ RapierPhysicsPipeline.physicsTick() — 9.78%
│ └─ Rapier3D.step() — 9.78%
│ └─ sable_rapier_x64_linux.so (native) — 9.03%
In an earlier profile on the same setup:
sable$tickPlotContainer() — 8.81ms/tick
sable$collideRedirect() — 8.09ms/tick
RapierPhysicsPipeline.physicsTick() → Rapier3D.step() — 8.34ms/tick
Both profiles show the same call stack dominating, at similar magnitude, despite zero sub-levels existing in the world at the time.
Question
Is the physics pipeline expected to step every tick unconditionally, or should it be skipping/short-circuiting when there are zero active sub-levels/bodies to simulate? If this is expected behavior, some documentation on the baseline cost would help server owners plan capacity. If it's not expected, happy to provide the full spark profile link or run additional diagnostics (I have Shtreimel installed already).
Full spark profile: https://spark.lucko.me/YHkIXyJCzq
Environment
Sable version: 1.2.2
Minecraft: 1.21.1
Loader: NeoForge 21.1.243
OS: Ubuntu 24.04.4 LTS (amd64), kernel 6.8.0-106-generic
CPU: AMD EPYC (12 threads available)
Java: 21.0.11, OpenJDK 64-Bit Server VM
Related mods installed: Create Aeronautics, sablecompanion, sable_sa_compat, create_mekanism_compat, Shtreimel (diagnostic tool)
Description
On a freshly generated world with no player-built ships, platforms, or sub-level structures whatsoever, Sable consistently accounts for ~13-16% of total server tick time across multiple profiling sessions. The cost appears constant regardless of world content, which suggests the physics pipeline is stepping every tick unconditionally rather than only when active sub-levels exist.
Profiling data (via spark)
Server thread total: ~113ms/tick average in one session (target is 50ms for 20 TPS)
Sable's call stack breakdown (Merge mode, Percentage label):
sable (v1.2.2) — 15.76% of server thread
├─ ServerSubLevelContainer.tick() — 10.40%
│ └─ SubLevelContainer.tick() — 10.58%
│ └─ SubLevelPhysicsSystem.tick() — 10.25%
│ └─ SubLevelPhysicsSystem.tickPipelinePhysics() — 10.22%
│ └─ RapierPhysicsPipeline.physicsTick() — 9.78%
│ └─ Rapier3D.step() — 9.78%
│ └─ sable_rapier_x64_linux.so (native) — 9.03%
In an earlier profile on the same setup:
sable$tickPlotContainer() — 8.81ms/tick
sable$collideRedirect() — 8.09ms/tick
RapierPhysicsPipeline.physicsTick() → Rapier3D.step() — 8.34ms/tick
Both profiles show the same call stack dominating, at similar magnitude, despite zero sub-levels existing in the world at the time.
Question
Is the physics pipeline expected to step every tick unconditionally, or should it be skipping/short-circuiting when there are zero active sub-levels/bodies to simulate? If this is expected behavior, some documentation on the baseline cost would help server owners plan capacity. If it's not expected, happy to provide the full spark profile link or run additional diagnostics (I have Shtreimel installed already).
Full spark profile: https://spark.lucko.me/YHkIXyJCzq