Is your feature request related to a problem?
Around a decade ago the Bukkit API swapped to creating snapshots when creating BlockState objects with a raw getState() method, which was magnitudes slower than beforehand. Paper created a getState(boolean) method as a workaround, to allow plugins to opt-out of the snapshot behaviour. This is good, but many plugins don't realise and instead opt for the significantly slower snapshot variant.
Describe the solution you'd like.
Paper should change the default behaviour to not create snapshots, and instead have usecases that require snapshots go through getState(true) instead. This would make code performant by default, which fits Paper's general goals.
This change should be made across all method calls that create a BlockState instance, not just Block#getState().
Describe alternatives you've considered.
An alternative would be to deprecate the raw method entirely, so that developers are forced to confront the choice of "do i need a snapshot or not". This of course would mean that the change would not affect existing plugins, and would require developers to fix things.
Other
This should ideally not be too breaking of a change. A vast majority of plugins function identically with or without snapshots.
When the snapshot system was initially created, a Sign was 1600x slower than the non-snapshot equivalent. Signs being one of the simplest tile entities at the time. The game has only increased in complexity, and the slowdown is entirely dependent on the types and quantity of data that are being pulled in. In 1.21.4 chests can be upwards of 100000 times slower depending on what's inside them. I've seen numerous Spark reports that show half the entire server tick being used entirely by plugins doing a handful of chest accesses on chests that contain a large amount of data.
I've created a branch that appears to do this, but i haven't fully gone through and checked that it covers absolutely every code path. PR at #11913; should have a PR jar attached if someone wants to test it out with their plugins/server setups.
Is your feature request related to a problem?
Around a decade ago the Bukkit API swapped to creating snapshots when creating BlockState objects with a raw
getState()method, which was magnitudes slower than beforehand. Paper created agetState(boolean)method as a workaround, to allow plugins to opt-out of the snapshot behaviour. This is good, but many plugins don't realise and instead opt for the significantly slower snapshot variant.Describe the solution you'd like.
Paper should change the default behaviour to not create snapshots, and instead have usecases that require snapshots go through
getState(true)instead. This would make code performant by default, which fits Paper's general goals.This change should be made across all method calls that create a BlockState instance, not just
Block#getState().Describe alternatives you've considered.
An alternative would be to deprecate the raw method entirely, so that developers are forced to confront the choice of "do i need a snapshot or not". This of course would mean that the change would not affect existing plugins, and would require developers to fix things.
Other
This should ideally not be too breaking of a change. A vast majority of plugins function identically with or without snapshots.
When the snapshot system was initially created, a Sign was 1600x slower than the non-snapshot equivalent. Signs being one of the simplest tile entities at the time. The game has only increased in complexity, and the slowdown is entirely dependent on the types and quantity of data that are being pulled in. In 1.21.4 chests can be upwards of 100000 times slower depending on what's inside them. I've seen numerous Spark reports that show half the entire server tick being used entirely by plugins doing a handful of chest accesses on chests that contain a large amount of data.
I've created a branch that appears to do this, but i haven't fully gone through and checked that it covers absolutely every code path. PR at #11913; should have a PR jar attached if someone wants to test it out with their plugins/server setups.