Some redstone components (rails,redstone torch,comparators,lever and buttons as far as I know) send duplicated block updates that cause unnecessary lag
This is because they have an onRemove method that is called when the state change (call to setBlock) that are responsible of the update order and then send other block updates after the setBlock call that are pointless (and not the same order as the first ones in the case of rails)
Related issues
relates to
Attachments
Comments
migrated
migrated
test with a mod I made that fix rails with about 320 blinking rails: 17 mspt to 10.5 mspt
note that rails are widely used in farms to avoid the lag from redstone dust
ampolive
Is this still the case in 1.19?
migrated
still in 1.19.1 rc2,
in PoweredRails.updateState and BaseRailBlock.onRemove for rails
onPlace and onRemove for redstone torches
same for button and lever
migrated
Still in 1.19.2.
Unlike what pwouik's last comment seems to imply, buttons and levers don't send the extra updates in their onRemove implementation. The extra updates come from the fact that despite the Level#setBlock call in the button's press and checkPressed methods and in the lever's pull method already send block updates (due to passing Block#UPDATE_ALL = 3 as the update flags), but then the button's / lever's own updateNeighbours method is called right after Level#setBlock, and that sends block updates to the button / lever's direct neighbors again before updating the neighbors of the block the lever / button is attached to.
[Mod] Jingy
Can you still reproduce this in the latest full release, 1.21.1? It would also be helpful to know if you can reproduce it in the latest snapshot 24w33a with the recent changes made to redstone and how it updates.