Consider switching to aborting on panic in hot ECS functions #12107
Labels
A-ECS
Entities, components, systems, and events
C-Feature
A new feature, making something new possible
C-Performance
A change motivated by improving speed, memory usage or compile times
P-Unsound
A bug that results in undefined compiler behavior
X-Controversial
There is active debate or serious implications around merging this PR
What problem does this solve or what need does it fill?
Some potentially very hot and heavily monomorphized ECS functions still have panics in the case something goes wrong. Panicking results in a lot of codegen, which can make binary sizes much larger, and can affect instruction fetch locality and thus performance in very hot ECS functions.
As seen via the asembly generation tests, there are still many locations where panics may crop up.
What solution would you like?
Create a utility called
AbortOnPanic
which turns all panics in the local scope into aborts, only in release mode.This technique is used by a number of fairly low level crates like
tokio
orasync-task
, where a panic would otherwise be an artifact of incorrect safety or correctness-related invariants not being satisfied. Any location where it's calling into user provided code (i.e. trait functions turned into function pointers) must be wrapped instd::panic::catch_unwind
to avoid aborting on user-provided code.This may also be a correctness and soundness issue, since panicking on unsatisfied invariant can be caught via
catch_unwind
, and leave the ECS in an invalid and unsound state.Note that this likely won't affect builds using
panic = "abort"
in their build profiles, but will likely improve the default--release
configuration that cargo provides.This should only be used in locations where we know that we're not calling into user provided code, and we should only be panicking
What alternative(s) have you considered?
Leaving it as is, panicking instead of aborting.
The other alternative is to use
std::hint::unreachable_unchecked
, which is both unsafe and very easy to result in undefined behavior is used incorrectly.The text was updated successfully, but these errors were encountered: