Redstone dust updates cause lag
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.
I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.
Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgas
Final note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however, this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
Possible solutions
Linked Issues
is duplicated by10
MC-92823Lever Tickrate LagDuplicateMC-94065Redstone lagDuplicateMC-117010Comparator/dropper clocks issueDuplicateMC-124086strange lag spikes when near redstone clocksDuplicateMC-138532Lag with redstone timerDuplicateMC-141585Extreme lags with redstone clocksDuplicateMC-146053Redstone lagDuplicateMC-164476Redstone Dust causes a ton of block updates when being unpoweredDuplicateMC-202844Unconnected BUD Switch with unpowered redstoneDuplicateMC-239001These lag machines will CRASH the serverDuplicate
Created Issue:
RS Block Updates = LAG (and a lot of it)
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however this "bug" has existed ever since redstone dust has been added to the game, all the way back in Alpha 1.0.1.
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however this "bug" has existed ever since redstone dust
hasbeenadded to the game, all the way back in Alpha 1.0.1.Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however, this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
RSBlockUpdates = LAG (and a lot of it)RS Dust Updates = LAG (and a lot of it)
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)
is duplicated by
relates to
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however, this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
is duplicated by
is duplicated by
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however, this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
Redstone dust causes immense amounts of lag on servers (including local SinglePlayer "servers"), and here's why (deduced from the game code, as well as a mod I wrote to help track down some redstone querks):
Except for a redstone dust block updating (at least) 23 blocks around it, every time it is placed or receives any sort of update, apparently, redstone dust also DOES NOT directly de-power, as you'd expect. Instead, it continually loses 1 signal strength until it's "satisfied" and a check fails, meaning it doesn't need to update anymore. The 15 signal strength levels it needs to lose (one-by-one, mind you), each time causing at least 23 block updates, all happening within 1 gametick (1/20th of a second, around 15 * 23 = 345 block updates in total) cause a lot of unnecessary calculations to be done. Not only that, but this example only involved one piece of redstone dust. Imagine the same happening with a line, or even a grid. There it's even worse, since the dust blocks update each other again and again multiple times in 1 single game tick, so that a line of 15 redstone dust can easily amount to around 2,500 block updates in total.
Each calculation is independently quite quick and simple, but any calculation run 2,500+ times in a 1/20th of second, where a lot of other calculations also need to run in that short time frame, is heavy, to say the least.I suggest rewriting the redstone dust update code, as it is quite simple and will reduce a whole load of lag on any server with redstone clocks running.
Redstone dust is a horrible lag causer, and it does so in one of the most unnecessary ways in the entire game.Here is a short clip demonstrating (using my mod, as mentioned above) how 1 piece of redstone dust alone causes 15 * 23 = 345 block updates when de-powering:
https://www.youtube.com/watch?v=T3bST3JGgasFinal note: The "Affected Version/s" field only allows set versions, and only the most recent ones, however, this "bug" has existed ever since redstone dust was added to the game, all the way back in Alpha 1.0.1.
Possible solutions
RedstoneWireTurbo.zip
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
is duplicated by
is duplicated by
is duplicated by
is duplicated by
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
Important
rockenroll4life (Josh Letellier)![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
![[Helper] Michał](../../../data/avatars/users/43368.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mojang] Panda](../../../data/avatars/users/41658.png){kind=small}
is duplicated by
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
![[Mod] Chandler](../../../data/assets/gravatar/triwonder81.png){kind=small}
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
is duplicated by
"Will you shut up, man?"
– Joe Biden
President of the United States of America
relates to
is duplicated by
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
I see a redstone-lag bugpost (imo falsely) duplicating this bugpost here: Fixed/changed now by Kumasasa, thank you }=)
In case any of you gets lag due to redstone contraptions: That might be MC-81098
We noticed a huge lag/lag spike problem with simple dust-piston-lever contraptions: There are maybe 10 redstone updates; everytime we switch the lever this causes the game to freeze, we thought possibly also due to lighting updates, but even encasing the pistons and everything and it being either in a void world or flatworld with no mobspawns didn't help.
We tested in 1.8 and 1.9, it already happens in 1.8, it's gotten worse in 1.9 though, and our hardware is really decent.
I'm just saying this here for those who might not know about the other post and might experience lag due to their redstone machinery.
It seems to me that there are different issues who can all lead to lag, and it isn't easy to separate all issues from each other, that's why it'd be better if we could separate them into either single bugposts or make some sort of table where we can refer to each of them separately, or it gets confusing, as this seems to be now some sort of "collection thread" (mobs pathfinding, mob amount, chunk loading etc.pp.) for anything regarding lag, and thus it might be more complicated to fix it, as we might be talking about different issues.
@Meri Diana I just asked, MC-81098 has nothing to do with changes from 1.8 to 1.9.
[~FaRoGaming] I'm about to upload a performance test video in MC-81098 with a more than decent hardware prerequisite.
As I said, it can be light updates issues, but redstone dust lag does for sure add to the problem.
And there IS a change between 1.8 and 1.9, as for the same mechanism (which, again, lags/lagspikes ALSO due to redstone dust, but that's NOT the main issue, it seems).
Might this be MC-81098? Redstone dust is used in the setup mentioned in the description and it causes lag.
As pointed out by [Mod] md_5 replacing the non-order-keeping HashSet with a oder-keeping one (e.g. LinkedHashSet) would make it symmetric regarding changes in position.
But the order would still be very directional and counterintuitive.
Also when fixing it, unnecessary block updates should be reduced (see MC-81098).
A possible way to update redstone in an "along the wire"-order and remove the performance issue on unpowering it, would be to first evaluate and set the new state of the whole wire and then cause each update just once along the wire.
The problematic case when turning off a wire that's still powered from an other source could be solved by turning off all connected wires (all that get powered by this one anyways) first.
When all of them are off they get turned back on starting from the other power sources.
I attempted to implement such a solution.
Mod: http://www.mediafire.com/download/okhobwmcj4e8jqa/1.10_RedstoneFix.zip
Code: https://gist.github.com/Panda4994/70ed6d39c89396570e062e4404a8d518
Video: https://www.youtube.com/watch?v=NEMARMNvDsw
The main goals of the implementation were:
- Reduce unnecessary updates
- Make the update order more logical and predictable
- Keep old behaviour working
Some of the changes made in the mod are simple improvements and I doubt they have downsides.
For example when the blocks around the wire get updated it used to update all surrounding blocks of all surrounding blocks and itself.
So each time a wire updates its neighbors 42 block updates are caused, while 18 of them are repetitive (17 if the update on itself is needed).
To avoid that I made a static List of Vec3i containing the offsets of the positions that need to be updated.
However, other changes are a bit weird or imply some follow-up changes on other redstone components.
- The entire wire changes its state before causing any updates.
This quite a change but in the 1.9 update the same was done to pistons, so it seems logical to apply it to redstone too.
- Needed updates are caused first
In the mod blocks that actually get powered by the wire get updated first.
To do so I created a method canBlockBePoweredFromSide() which checks if a block can receive redstone power from a certain side.
At the moment it is a bunch of instanceof-cases for all blocks that have special behaviour regarding redstone.
If this was actually adapted it should probably be changed to be a method of Block.java that gets overridden by the blocks with special behaviour regarding redstone and works with a fancy PowerSource-Enum and stuff like that.
There are two reasons why this is needed.
The first one is that there are cases where updates from the start of the wire could cause changes on blocks further back, making the order of changes less logical again.
The piston on the right is connected closer to the power source, but without this check the one on the left would receive an update first.
- The second reason for it is that not really needed updates are caused in a reverse order and after the needed ones.
This is probably the weirdest quirk in the mod.
The not-really-needed-updates are updates that will only have an effect on block update detectors.
The only reason I put them in is to keep old behaviours working. For the same reason they are in a backwards order, because that is closer to the order the recursive updates would have generated.
I know this is a weird and specific quirk, but I found a few (very timing specific) builds that would break if the order wasn't reversed for these updates.
- The updates travel from the first UPDATED wire outwards.
For example if there is a lever in the center of a diamond shape of redstone wire and you turn it on, you would probably expect the updates to wander out in a diamond shape as well.
However currently the wire west of the lever will turn on first, as it receives the initial update and then the diamond shape emerges from there.
This is something that's not perfect with the mod yet, but changing it would require to change how other blocks trigger redstone updates.
As the mod already works with sets of wire positions, it would be possible to make some adjustments to allow triggering the algorithm with several wire positions instead of just one.
So all wires around a lever could be added to the set, before the algorithm starts working.
In case this idea would be considered, there might be many more elements on the lists in some cases.
So it might be necessary to replace the current use of lists and contains calls as set with a remove-first-method with something with a less expensive contains implementation.
- The updates around a single wire also follow a closest-first order.
This is not so much a problem than rather a logical conclusion from the decision to make the update order logical.
But it feels inconsistent with how other redstone components currently update their surrounding blocks.
So I think if this fix was used, other redstone components such as repeaters or torches, should use an update order following the same principles.
However this would break quite a few old designs, as repeaters and torches already follow an order. (Other than redstone wire for which the order was basically random before, which gives the freedom to just decide on a good order without breaking designs)
This is the main concerns I have with this fix, but I would like to get some feedback on it.
Also I would be interested in finding designs that worked position independent before, but won't work in the fix. I tried quite a few huge and fast builds, but the only things that broke were positional before, so it's unavoidable for them when fixing this bug.
Dupe of MC-81098
Hi, everyone,
I have been working for nearly a month, in most of my spare time, on finding ways to improve the performance and undesirable behaviors of redstone wire. Depowering can be especially compute-intensive, and update order is both random and nondeterministic due to HashSet behavior. I have focused my attention on the execution critical path for computing new wire power levels and propagating them to neighbors, and I have found many inefficiencies whose mitigation would improve Minecraft performance across the board. For instance, there are multiple methods in World that compute the 6 cardinal neighbors of a given block position. During redstone wire depowering, the neighbors of the same positions are recomputed over and over again. BlockPos objects are immutable, so repeating the same work introduces wastes a great deal of time, and I found a simple caching mechanism to yield a significant performance boost. However, since this and other such global optimizations are not specific to redstone wire, I will not be presenting them here.
Before I continue, I realize that the developers are very busy with the 1.13 snapshot. However, it is during snapshot periods that instabilities and behavioral changes are expected, making this an ideal opportunity to identify any undesirable effects. Moreover, this is also an opportunity for developers to offer an olive branch to the technical community, addressing two problems that affect them severely, serious lag and inconsistent behavior.
Some time ago, our esteemed friend Panda4994 uploaded an improved implementation of BlockRedStoneWire. I skimmed quickly over his code, and I had also read a great deal of the comments on this bug report, albeit a very long time ago, so some statements below may be inaccurate. From what I can gather, the reasons that Mojang declined to implement Panda's improvements include the following:
- It affected code outside of BlockRedstoneWire and/or replicated code from elsewhere in Minecraft.
- Concerns were raised about changes to block update order breaking existing redstone contraptions.
- It's a ground-up rewrite of BlockRedstoneWire, which would require too much developer time to analyze and reimplement in the real Minecraft code.
- Something about it being "messy," although I'm not sure what that's supposed to mean.
While I would not be at all surprised if Panda's implementation outperformed mine, I have set out to develop an accelerator for redstone wire that is more likely to be adopted because it addresses each of the above concerns, as follows:
- No Minecraft code outside of BlockRedstoneWire is affected by this accelerator.
- Changes to BlockRedstoneWire are minimal.
- The bulk of the new functionality is implemented in a new helper class, making it straightforward to drop the new code into Minecraft with negligible refactoring.
- The helper code is carefully written, with copious commenting in order to make its operation as clear as possible.
You can think of this accelerator code as being analogous to a bolt-on after-market supercharger that is designed for minimal installation effort. (Despite the fact that I used the word 'Turbo' in the class name, I do know the difference between a supercharger and a turbocharger. 'Turbo' sounds cooler and uses fewer letters.)
You can find the new code in the file "RedstoneWireTurbo.zip" attached to this bug report. Inside, you will find the following files:
- BlockRedstoneWire.java – Updated version of BlockRedstoneWire that implements the 45% performance improvement I posted about earlier and hooks into the helper class that contains the optimized redstone wire code.
- BlockRedstoneWire.diff – The differences between the vanilla BlockRedstoneWire code (from MCP for 1.12.2) and the modified version.
- RedstoneWireTurbo.java – Helper class that implements the improved and performance-optimized redstone wire update algorithm.
Main features of this redstone wire performance accelerator include the following:
- As stated above, changes to BlockRedstoneWire are very limited and no other classes are affected.
- The choice between old and new redstone wire update algorithms is switchable on-line.
- The unmodified Minecraft code relies on World.notifyNeighborsOfStateChange for redstone wire blocks to communicate power level changes to each other, generating 36 block updates per call. This optimized implementation propagates power level changes directly between redstone wire blocks. Redstone wire power levels are therefore computed more quickly. Since redstone power level states are computed internally, no block updates are necessary from redstone wire to redstone wire. Block updates are sent only to non-redstone blocks, many of which may perform an action when informed of a change in redstone power level.
- Of the 36 block updates generated by a call to World.notifyNeighborsOfStateChange, 12 of them are obviously redundant (e.g. the west neighbor of the east neighbor). These are eliminated.
- Updates to redstone wire and other connected blocks are propagated in a breath-first manner, radiating out from the initial trigger (a block update to a redstone wire from something other than redstone wire).
- Block updates are scheduled both deterministically and in an intuitive order. This addresses bug MC-11193.
- All redstone behavior that used to be locational now works the same in all locations.
- A few behaviors still depend on orientation; for instance, west is processed before east.
- Information that is otherwise computed over and over again or which is expensive to to compute is cached internally for faster lookup. This includes coordinates of block position neighbors and block states that won't change behind our backs during the execution of the search algorithm.
- Redundant block updates (both to redstone wire and to other blocks) are heavily consolidated.
- For worst-case scenarios (depowering of redstone wire) this results in a reduction of block updates by as much as 95% (factor of 1/20). Due to new overheads and old inefficiencies, empirical testing shows a speedup better than 6x. This addresses bug MC-81098.
- Worst-case powering-on has block updates reduced by a factor of about 8.8. Real time performance performance boost is about 61%.
Extensive testing has been performed to ensure that existing redstone contraptions still behave as expected. Results of early testing that had identified undesirable behavior changes were addressed. Additionally, real-time performance testing revealed compute inefficiencies with earlier implementations of this accelerator. Some compatibility adjustments and performance optimizations resulted in harmless increases in block updates above the theoretical minimum. That being said, 1.13 already introduces some important changes to redstone behavior. For instance, observer and comparator update priority have been reversed, which risks breaking many redstone designs that rely on specific within-tick update orders. Any changes to update order caused by my accelerator are likely to have less impact.
This redstone accelerator was first implemented on my testing server and has now also been added to carpet mod. The consensus of the testers (which include moderators from Mojira, members of SciCraft and ProtoTech, and other experts in redstone design) is that the changes are a distinct improvement over the current implementation. Observations include:
- Block updates that used to be random and nondeterministic all now make sense.
- The activation of other redstone components now follows an order that is strictly a function distance from the input signal.
- Some machines that used to work or not work depending on location now work the same regardless of location.
- Zero-tick behaviors are preserved and are now 100% reliable regardless of position and orientation.
- Numerous complex test cases were built, none of which showed any breakages (with one caveat, explained below), and the only changes observed were some really behaviors that made no sense before are eliminated, replaced by reliable, deterministic, intuitive behavior.
The only "breakage" that remains is one found by ilmango. To get an instant dropper line, there is this weird hack involving powered and activator rails and quasiconnectivity. This trick wasn't completely reliable, though, sometimes breaking depending on position or orientation. With the optimized redstone code, it no longer works at all. HOWEVER, with the optimizations, all you have to do to get an instant dropper line is to lay redstone wire on top of a line of droppers and power the wire at the input end of the dropper line. Where this previously did not work in all orientations, it now world 100% reliably in ALL orientations. This includes vertical (where you spiral blocks and redstone wire up or down around the droppers).
As I mentioned above, there are many other optimizations that can be made, but most of them can be implemented independently and will synergize with this one.
I have the following individuals and more to thank for their help in testing this new code:
- pokechu22 (Mojira)
- MethodZz (SciCraft)
- WARBEN
- NarcolepticFrog (ProtoTech and SciCraft)
- CommandHelper, aka nessie (ProtoTech)
- ilmango (SciCraft)
- OreoLamp
- Xcom6000 (SciCraft)
- tryashtar (Mojira)
- RedCMD
- Smokey95Dog (ProtoTech)
- EDDxample
- Rays Works (ProtoTech)
- Nodnam
- BlockyPlays (FrostCraft)
- TT (Dugged), for his jungle tree farm
Hi, Rikard,
First, I want to I express my deepest gratitude for your openness and friendliness towards the Minecraft user community. So please forgive me if I am overstepping any bounds, particularly with respect to the proper use of the Mojira comments section. If you wish to discuss this further in another forum, others at Mojang can provide my contact info.
You mentioned redstone wire, and this is something I know about, so I thought I'd mention a few things. Redstone wire makes heavy use of getBlockState too, so caching block states helps A LOT, but those are only linear-factor speedups. There are bigger problems with the way redstone wire is implemented. See MC-11193 and MC-81098 and my final comment on the latter.
I developed a non-invasive "bolt-on supercharger" for redstone wire that speeds it up by 10x (in our test cases; in terms of computational complexity, it's better than a linear speedup), makes it behave more intuitively, and removes the nondeterminism affected by location and orientation. Grum gave me some stringent requirements for this enhancement to be "acceptable," and I met them all. It has also developed some popularity among the "vanilla plus" modders. I understand that there are some Microsoft policies that inhibit use of outside code, but maybe we can get around that with an appropriately-worded contract and/or NDA that lets me or someone at Mojang port it to the internal codebase and coding style. (I am only interested in making Minecraft better and will freely, no-strings-attached hand over legal rights for this code to Mojang.)
That all being said, redstone wire performance is "merely" a performance problem. There are much more serious data loss bugs like MC-119971, MC-108469, and MC-2025 that maybe should have higher priority, all of which have community-provided fixes.
Thanks you again for your time, patience, care, and enthusiasm!
Thank you for your report!
However, this issue has been closed as a Duplicate of MC-81098.
It has been linked to this report. If you have additional information, please add it to the duplicated report.
Please search before reporting, as it's likely that one exists already.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
Thank you for your report!
We're actually already tracking this issue in MC-81098, so I resolved and linked this ticket as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – 📖 Game Wiki
my issue resolved itself after 5 minutes of doing nothing. It is caused by the tree farm, which still has severe redstone lag, which is described in MC-81098
Arthur Zhou In case this happens all the time when you activate your tree farm, would it be possible for you to attach the world download to this report?
The way the game hangs seen in the video does not match MC-81098. From the video it appears that the internal server got hung on a single tick for a long time. MC-81098 would slow down ticks, but not to this extend unless there is a couple thousand redstone dust activated in the same tick, which doesn't seem to be the case here.
Not intended, but Redstone Wire causing too many updates is a very old issue and tracked here: MC-81098
4 years ago, when the first rendition of the Observer was added, one could see this very beautifully: Demo video 10/2016 The demo starting at 0:39 is imo especially scary : ))
- Mojang has been aware of this for years
(Duplicates MC-81098) - Please don't use the bug tracker to promote YouTube channels/videos.
Thank you for your report!
We're tracking this issue in MC-81098, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Dupe ofMC-76561@Sonic I disagree. He is talking about lag, not knowing what causes it, as well as talking specifically about 1.7 worlds running in 1.8 servers. I am talking about (pretty much) all versions of Minecraft, while also providing proof and a thorough explanation of the phenomenon.
Is any of this a "feature" to Redstone designers that would have to be considered before rewriting the implementation? (The performance savings sounds worthwhile regardless. I'm just curious.) For example, if two things on the same circuit are at power-13 and power-12, will the power-12 one always depower first, and does that ever matter?
I read your note about the affected versions but you should still specify it as all the versions it allows you to select.
@TRS as of this moment you can only select the current version 1.8.7, so he has selected everything he can.
Well this explains a lot.
@m0rsk - It might matter for some very specific redstone designs, but very few if it does. Don't think it does. The order things get powered makes a lot more difference than the order they lose power.
could you test it with your mod + optifine on? im curious to see if optifine has this fixed
Interesting. [Mojang] Grum (Erik Broes) has talked about overhauling how redstone is implemented for various reasons, but hasn't gotten around to it because they've been busy with other massive changes to the game engine. Considering Notch's coding style, the current implementation was probably designed as a brute force approach to ensuring signals propagated correctly under all circumstances, knowing that a more efficient solution probably existed, but not wanting to expend the effort to find it unless necessary. You say that this is a simple fix, can you provide some code examples of the necessary changes?
Is this the same bug? youtu.be/uNX6evLpAkw?t=7m35s
It seems to be way worse in 1.9 than in 1.8.
Not really the place for it, but that most definitely looks to be because of lag, but I see not reason to assume it's just because of the redstone. I'd think there's something else going on on that server, or they just decided to take the 10 dollar option this time. Anyway, no real point in thinking about what could be the cause on someone else's server with many other things going on.
No, they have run an 1.8 world with about 20-30 redstone related YouTubers on it without mayor problems. This is the start of a new world in 1.9 and it already lags that much.
There is no reason to think this has changed from 1.8 to 1.9. This isn't the place for baseless assumptions.
Ok, then this is probably not the bug report I'm looking for. Thank you!
Performance video/example attached. Edit: Look not only at the lagspikes, have an eye on "chunk updates"
Although one needs to assume that the real lag "culprit" are light updates, the lag caused by redstone seems to add to it, as far as we can tell.
Comparing the lag/lag spikes of the same thing between 1.8 and 1.9 shows that it was already existing in 1.8, but 1.9 made it worse.
Whatever caused this change, it's making redstone-/piston-related contraptions unplayable even for more than decent hardware, let alone people with generic normal or bad computers.
@Mods: Is there any bugpost where people complain about lag caused possibly by light updates?
After
MC-94438I feel we should gather all lag posts if that would be possible in a way, to have an overview."Relates to" would be likely not the correct term, but I'm out of my wits in how we could gather and address all possible lag issues, so Mojang could work on all of them alongside.
@Meri Diana
There is a bug report for lag created by huge lighting updates
MC-11571, but not one specifically for 1.9.The only source of light reaching the pistons in that video is the redstone torch, right? Does the lag disappear if you remove it(and power the pistons differently)?
Nasm Nasmus I just asked Spire (RedstoneSpire) to be so kind to reply to that, he setup that contraption and is more suited than I could ever be regarding redstone };]
He'll get back to you asap.
sorry for meta-discussing @mods
I attempted to create a fix for this and MC-11193.
There is a more lengthy post about it over at MC-11193.
Also I can confirm for 1.10.2
I wonder if having redstone set itself to its highest received power level, instead of decreasing by 1, would not break anything. Should in theory cut, by about 50%, the number of updates when turning off a wire. I still think the mod Panda made is better but I'm just trying to suggest something Mojang could do that would be better than what we have now.
Confirmed for 16w41a.
Hi, Everyone,
I have been investigating this issue and MC-11193 for some time now. I have two optimizations that I want to present, both of which affect exclusively BlockRedstoneWire. I have a more advanced optimization (also confined to BlockRedstoneWire) that is so far making redstone wire depowering 23 times faster and also fixes MC-11193, without breaking any of the numerous tests we have performed (other than removing nondeterminism and counterintuitive update orderings). More on that when I am more confident.
But for right now, I'm just going to present a really simple change that results in a 45% improvement in speed for redstone wire depowering.
I'm working from MCP code decompiled from 1.12.2. There is a method called BlockRedstoneWire.calculateCurrentChanges, with the following signature:
private IBlockState calculateCurrentChanges(World worldIn, BlockPos pos1, BlockPos pos2, IBlockState state)And here is pseudocode for important steps it performs:
The optimization is as follows:
j = l-1; if (k > j) j = k;If you're super paranoid that k might be out of range for whatever reason, you can put back in otherwise redundant checks to make sure that j is in the range of 0 to 15.
Here is what this accomplishes:
I and several others (people from SciCraft, two from Mojira, and other technical users and modders) have tested this extensively. Nobody has observed any behavioral changes at all. All they noticed was that you could do about twice as much work before experiencing lag. In fact, Xcom added it to carpet mod, and SciCraft's creative server has been running it for a while now, and nobody has noticed anything.
I hope the developers will consider implementing this simple change.
Thanks.
Update: I totally didn't notice Bengineer8's comment, which anticipated what I implemented by more than a year. He totally deserves recognition for his suggestion. And to answer his question, YES. We've had maybe a dozen people (modders, mojira moderators, expert players) testing the heck out of this implementation. Absolutely no behavioral changes have been identified. The change has been in carpet mod for some time now on SciCraft CMP for quite a while, and even the most esoteric things that rely on quirks of redstone update order seem to be completely unchanged in behavior.
I realize that the devs are busy with a snapshot. But snapshots are naturally times when people expect bugs and instability. So now might actually be the best time to introduce this optimization.
@Timothy Miller
Thank you for the recognition. Glad that it doesn't break anything and som1 implemented it. : )
I agree that now would be a great time to implement it but I doubt they will but who knows?
Hi, everyone,
I have been working for nearly a month, in most of my spare time, on finding ways to improve the performance and undesirable behaviors of redstone wire. Depowering can be especially compute-intensive, and update order is both random and nondeterministic due to HashSet behavior. I have focused my attention on the execution critical path for computing new wire power levels and propagating them to neighbors, and I have found many inefficiencies whose mitigation would improve Minecraft performance across the board. For instance, there are multiple methods in World that compute the 6 cardinal neighbors of a given block position. During redstone wire depowering, the neighbors of the same positions are recomputed over and over again. BlockPos objects are immutable, so repeating the same work introduces wastes a great deal of time, and I found a simple caching mechanism to yield a significant performance boost. However, since this and other such global optimizations are not specific to redstone wire, I will not be presenting them here.
Before I continue, I realize that the developers are very busy with the 1.13 snapshot. However, it is during snapshot periods that instabilities and behavioral changes are expected, making this an ideal opportunity to identify any undesirable effects. Moreover, this is also an opportunity for developers to offer an olive branch to the technical community, addressing two problems that affect them severely, serious lag and inconsistent behavior.
Some time ago, our esteemed friend Panda4994 uploaded an improved implementation of BlockRedStoneWire. I skimmed quickly over his code, and I had also read a great deal of the comments on this bug report, albeit a very long time ago, so some statements below may be inaccurate. From what I can gather, the reasons that Mojang declined to implement Panda's improvements include the following:
While I would not be at all surprised if Panda's implementation outperformed mine, I have set out to develop an accelerator for redstone wire that is more likely to be adopted because it addresses each of the above concerns, as follows:
You can think of this accelerator code as being analogous to a bolt-on after-market supercharger that is designed for minimal installation effort. (Despite the fact that I used the word 'Turbo' in the class name, I do know the difference between a supercharger and a turbocharger. 'Turbo' sounds cooler and uses fewer letters.)
You can find the new code in the file "RedstoneWireTurbo.zip" attached to this bug report. Inside, you will find the following files:
Main features of this redstone wire performance accelerator include the following:
Extensive testing has been performed to ensure that existing redstone contraptions still behave as expected. Results of early testing that had identified undesirable behavior changes were addressed. Additionally, real-time performance testing revealed compute inefficiencies with earlier implementations of this accelerator. Some compatibility adjustments and performance optimizations resulted in harmless increases in block updates above the theoretical minimum. That being said, 1.13 already introduces some important changes to redstone behavior. For instance, observer and comparator update priority have been reversed, which risks breaking many redstone designs that rely on specific within-tick update orders. Any changes to update order caused by my accelerator are likely to have less impact.
This redstone accelerator was first implemented on my testing server and has now also been added to carpet mod. The consensus of the testers (which include moderators from Mojira, members of SciCraft and ProtoTech, and other experts in redstone design) is that the changes are a distinct improvement over the current implementation. Observations include:
The only "breakage" that remains is one found by ilmango. To get an instant dropper line, there is this weird hack involving powered and activator rails and quasiconnectivity. This trick wasn't completely reliable, though, sometimes breaking depending on position or orientation. With the optimized redstone code, it no longer works at all. HOWEVER, with the optimizations, all you have to do to get an instant dropper line is to lay redstone wire on top of a line of droppers and power the wire at the input end of the dropper line. Where this previously did not work in all orientations, it now world 100% reliably in ALL orientations. This includes vertical (where you spiral blocks and redstone wire up or down around the droppers).
As I mentioned above, there are many other optimizations that can be made, but most of them can be implemented independently and will synergize with this one.
I have the following individuals and more to thank for their help in testing this new code:
I uploaded a replacement RedstoneWireTurbo.zip. I took some suggestions for clearer variable names, spelling correction in the comments, etc.
After some time of people testing my older redstone wire accelerator and using it in Carpet Mod, I was very pleased to have the opportunity to show it to Grum. He liked the fact that it was non-locational and deterministic. His main complaint was that it was still directional (some behaviors would change depending on orientation).
After a lot of work and a few false starts, I solved that problem too. The bread-first traversal of redstone wire implemented by the accelerator works out the direction of information flow, which we'll call "forward." The redstone wire and other block updates are now stored in a left-to-right ordering, which is inherited through wire fanouts. As a result, the new implementation is now also non-directional, where left always wins over right when there are conflicts (like pistons pushing into the same space). Overall, this enhancement makes redstone wire faster, behave the same regardless of position and orientation, deterministic (exception explained below), and much more intuitive. (Other redstone components are unchanged, so it's still possible to get directionally-affected behavior when using things like repeaters, redstone torches, etc.)
It is possible to build ambiguous machines, where "forward" cannot be determined (e.g. wire is powered from below); in that case, initial ordering is decided randomly. (Something that Grum said he prefers over position and orientation dependencies.) Since you can design your machines explicitly to have ambiguous orientation, this randomization can be made to occur when you want it to and put to good use. (NarcolepticFrog built one such machine on my testing server.)
My previous version (the one uploaded to Mojira) also broke compatibility with a few obscure redstone designs. For instance, ilmango showed me an instant dropper line that used alternative powered and activator rails. I found ways of fixing these incompatibilities by generating some specific extra block updates (e.g. above and below the current position at Y+2 and Y-2 get double updates, but at different times). (With the accelerator, you can now make instant dropper lines just by laying redstone wire on top of droppers.) On my redstone testing server, as far as I know, there are no contraptions that work with vanilla but break with the accelerator. On the other hand, there are lots of new contraptions that used to behave in weird or inconsistent ways that now all work in completely sensible ways. Xcom put my latest code into Carpet Mod, so SciCraft CMP and a few other tech servers have been running this for some time now, with no complaints.
While I was at it, I made some other code optimizations, and now the accelerator boosts redstone peformance by about a factor of 10. (That factor of 10 accounts for both powering and depowering of redstone wire, along with other CPU overhead on the main thread.)
Before I attach my new code here, Pokechu22 has been working on some improvements to code clarity. There are a few arrays of ints that are hard to interpret, although the comments explain them. He has been working on turning those into enums. If Enum.ordinal() isn't completely optimized away by the JIT compiler, or there are other performance impacts, one thing we can do is provide the code wth arrays of Enums that are converted at load time, in a static {} block, into int arrays.
If you want to look at my latest version, here is a link to my dropbox:
https://www.dropbox.com/sh/hk586vbdb9pl18o/AADNLMisAzIL2yzHQclObpCua?dl=0
BlockRedstoneWire.java is the MCP decompile of the redstone wire class, plus the changes necessary to bolt on the accelerator. A unified diff against the original is provided in BlockRedstoneWire.diff. RedstoneWireTurbo.java contains the accelerator itself. The source files also include some boolean flags to enable/disable different acceleration features. The code is very heavily commented, and I have tried very hard to make it understandable, but I would be happy to receive constructive criticism (probably on /r/Mojira or EigenCraft).
I was able to lag a strong server to less than 1tps with a lot of blinking redstone dust
But with the fix enabled I could run at a solid 20tps, even on my Chromebook!
This would be a very good fix to do in 1.15 as it's intended as a bug fix update. Incredible work by the community, it fixes almost any redstone lag on my test server.
My redstone accelerator is now integrated into the core of the Paper server modding framework. You can turn it on using a config file entry. Thank egg82 for doing the integration work.
Still in 20w18a
Can confirm 1.16 pre release 5
Still present in 1.16.1
Related to
MC-190891Can confirm for 20w27a
In 1.17.1 and 21w39a with setting priority updates: nearby
21w44a
can confirm in 1.18.1
Extra code analysis can be found in
MC-164476Hi all,
Like a few before me I have attempted to fix some of the issues with the current implementation of redstone dust. It is both laggy and unpredictable, making it a pain to work with, and leading to it being the most avoided redstone component in the game. Before I get to my solution to these issues, though, I want to acknowledge the work done by Timothy Miller and [Mojang] Panda, as both have been an inspiration in one way or another.
My implementation is mainly developed as a Fabric mod but has also been implemented into Paper.
Like the other two implementations, mine does not solely address the lag issue. It is a complete re-write of the power propagation code, fixing MC-11193 in the process. It is not a re-write of redstone as a whole, however. I attempted to keep existing behaviors as much as possible while fixing the lag of and inconsistencies with redstone dust that make it hard to rely on. To be more specific, it addresses the following issues:
1. Redstone wire does unnecessarily many calculations. Each wire in a network may calculate and update its power level over half a dozen times before settling on its final value. Moreover, each time it does so, it updates itself six times, doing even more completely redundant calculations.
2. Redstone wire emits unnecessarily many shape and block updates. This is, of course, related to the previous point, as a wire updates all neighboring blocks (and itself) each time it updates its power level. However, even if only the previous point is fixed, there would be many redundant shape and block updates that can be removed.
3. Redstone wire behaves unpredictably. The order in which a wire updates neighboring blocks is dependent on the location of the wire. Combined with the chaotic nature of the brute-force algorithm with which it updates, this makes it nigh impossible to predict and rely on how a wire network behaves.
I have designed a wire handler that addresses these issues in the following ways:
order.
Can confirm in 23w07a.
Can confirm in 24w13a.
Can confirm in 1.20.5.
Affects 1.21