MC-32933setBlock() lighting performance issue
Being a modder, I created a few things out of blocks. Tap something on the ground, and presto, something interesting, like a giant tree shows up. I had always wondered why it took more than 10 seconds on a screaming-fast gaming machine to display a generated tree that was surely less than 1000 blocks. I found out...
As part of creating another dimension, I generated floating islands. But what good is a floating island if it doesn't move? Even after all the optimization I could possibly muster, changing the absolute minimum number of blocks foe the islands to relocate, the results were still dismal. My islands were small, and slow, or I got severe lag. I appeared to be limited to less than 100 setBlock() calls a second.
Deciding to investigate setBlock() I tracked it down and commented out the Lighting routines. Presto. Instantly 1000 times faster. A ten-second tree generation was now instant. Islands were huge and moved at a nice clip.
Mystery solved.
The bug here, is that the lighting algorithms in setBlock() are what is causing excessive lag, everywhere, all the time. It doesn't take much. If I can only push 100 blocks a second on a high-end screamer, this would explain all the lag on my son's slower machine, and why it doesn't run on my laptop.
So, while my islands and trees now have a few funny shadows, at least I don't lag the game any more! 
PLEASE consider re-writing/re-vamping the World.setBlock() lighting algorithms. They are painfully slow.
Environment
Hi-End corei7 gaming PC, 64-bit java, etc.
MC 1.7.x
Created Issue:
setBlock() lighting performance issue
Being a modder, I created a few things out of blocks. Tap something on the ground, and presto, something interesting, like a giant tree shows up. I had always wondered why it took more than 10 seconds on a screaming-fast gaming machine to display a generated tree that was surely less than 1000 blocks. I found out...
As part of creating another dimension, I generated floating islands. But what good is a floating island if it doesn't move? Even after all the optimization I could possibly muster, changing the absolute minimum number of blocks foe the islands to relocate, the results were still dismal. My islands were small, and slow, or I got severe lag. I appeared to be limited to less than 100 setBlock() calls a second.
Deciding to investigate setBlock() I tracked it down and commented out the Lighting routines. Presto. Instantly 1000 times faster. A ten-second tree generation was now instant. Islands were huge and moved at a nice clip.
Mystery solved.
The bug here, is that the lighting algorithms in setBlock() are what is causing excessive lag, everywhere, all the time. It doesn't take much. If I can only push 100 blocks a second on a high-end screamer, this would explain all the lag on my son's slower machine, and why it doesn't run on my laptop.
So, while my islands and trees now have a few funny shadows, at least I don't lag the game any more!
PLEASE consider re-writing/re-vamping the World.setBlock() lighting algorithms. They are painfully slow.
Environment
Hi-End corei7 gaming PC, 64-bit java, etc.
MC 1.6.x
- Unresolved
- Open
- Unconfirmed
- lighting, performance setBlock,
- 1.6.4
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Hi-End corei7 gaming PC, 64-bit java, etc.
MC 1.6.xHi-End corei7 gaming PC, 64-bit java, etc.
MC 1.7.x
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
It would be really interesting if someone could test something like this with the lighting update routines disabled, much like MC-32933. That would really help narrow down whether this is a lighting update issue, or something internal to comparators or redstone.
I found the lag to be most significant when the items were travelling down, rather than up. There's a lot going on there, with the comparators, hoppers, and other redstone being toggled very rapidly as it limits the throughput of the items to ensure that the hoppers remain almost full of a particular item so they can be used to filter and sort. It may be overlapping calls, with a process not being completed before the state changes and the process is called again, constantly being interrupted.
Removing or placing a block forces the engine to recalculate whether or not a block is open to the sky, and recalculate the sky light level. Something in the process updates the beacon, causing it to re-evaluate the color of the beam. Replacing a block with setblock apparently doesn't trigger all of the same recalculations, even though it does immediately update skylight. Try replacing the glass with stone, for instance: the beam won't immediately be disabled.
If the glass is in the block immediately above the beacon, replacing it triggers a block update, which causes the beacon to update the beam immediately.
There may be a (significant) performance tradeoff (MC-32933) at stake here.
Unfortunately, it is taking MCP and Forge a looooooong time to update to the 1.7.2 sources, and so I can't test it yet (I build on the Forge platform, which I realize has it's own set of problems). I just wanted to make you aware that there was, at least in 1.6.4, a factor of tens of thousands difference in setblock() with and without lighting. I will report back again when I have 1.7.2 sources and have updated my own sources, and can test once again.
Thank you for responding, and not just tossing this bug aside. I'm a long-time (30+ years!) code-speed freak, so I notice these things...
It is taking far longer to find out than I had anticipated...
Please close this bug, and if it is still a problem whenever it is that I am finally able to upgrade, I will file a new one.
Sorry for the delay, but as you know, no one has been able to upgrade their mods to 1.7.x yet.
I hope future upgrades will go a little more smoothly.
And please prod someone over there to get cracking on the modding API...
Thanks!
Closed. You may ask us to reopen this one at any time.
I have just recently updated the OreSpawn mod to 1.7.4. This gave me the opportunity to try out the latest setBlock() function. The results are absolutely dismal.
To get around a huge lag problem in 1.6.4, I had realized that performing my small decorations inside chunk creation was infinitely faster than doing the decorations in the "proper" place in the world generation function. This is because the chunk is sent out as, well, one big chunk. This is hundreds of times more efficient than sending thousands of little setBlock() updates. So I took the time to more all my small decorations and ore generation into the chunk generators for my dimensions. It worked fantastically. No more network/CPU overload.
Using this same optimized code, I updated to 1.7.4. While the chunk generation is still fast, the remaining setBlock() calls are at least a factor of 100 slower. And that is without lighting, still using my optimized versions from 1.6.4 which bypassed it. In fact, the 1.7.4 setBlock() is now so slow as to make the giant tree and island generation for which my mod is known, impossible. It is unplayable. And that is on my high-end development machine.
In short: setBlock() has become so slow as to be completely dysfunctional when needing to set more than 10 blocks per second. Indeed, it is a factor of at least 10 times slower than the previous version (1.6.4) which was already painful. Now it is unusable.
PLEASE reopen. World.setBlock() has degraded in performance to the point where it is unusable.
I wish I knew. The basic problem is that Forge is so far behind the releases that it is impossible to give a timely update. I know the guy in charge of Forge is difficult (cough, cough) to work with, but they and MCP seriously need some help with staying current with the latest Minecraft versions. Could you do the modding community a big favor and just release a few huge swaths of code in source form for them? They need help. Modders need help. I'd absolutely love to contribute to helping Minecraft find and fix bugs, but it's impossible when I'm half a dozen releases behind.
I take it you're not aware that the person in charge of MCP, [Mojang] Searge (Michael Stoyke), is now a Mojang employee? Mojang has provided both the MCP and Forge teams with inside information in the past as well. It's not lack of information that holds them back, but the difficulty of getting the code to decompile, deobfuscate, recompile, and reobfuscate properly.
They're not going to release the actual Minecraft source code. The fact that mods are compiled against MCP, rather than the original source, is itself useful. They've shared small bits of code, and have shared a lot of information with the community. But their goal is to provide a plugin API that makes it unnecessary for people to decompile Minecraft in the first place. That's the cause of many of the sweeping changes to the codebase that have made it so difficult for MCP and Forge to stay up to date.
Wonderful. Thank you. I look forward to having a stable API!
Is this still a concern in the current Minecraft version 14w30c or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
This ticket is incomplete without the requested information, no response has been received within a reasonable time and we are assuming this is no longer an issue. If you are still experiencing this issue, we can reopen it at your request.
Please close/resolve this bug as FIXED.
I just tested it with MC 1.7.10 and it appears to be working again.
Thanks!