OpenSource/PaperMC
OpenSource/PaperMC
1
0
Fork 0
mirror of https://github.com/PaperMC/Paper.git synced 2024-11-25 00:30:25 +01:00
Code Issues Projects Releases Packages Wiki Activity
PaperMC/Spigot-Server-Patches/0382-Don-t-recheck-type-after-setting-a-block.patch

34 lines
1.3 KiB
Diff
Raw Normal View History

Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
From ab7e26676e388e98f45d9edb6bc48c3fc2d2de7d Mon Sep 17 00:00:00 2001
Don't recheck type after setting a block The server does a "Did my update succeed" check after setting a blocks data to a chunk. However, writes can not fail outside of a hard error or a a race condition from multiple threads writing, which is not something that should ever occur on the server. So this check is pointless, as if it did occur, the server would be having data corruption issues anyways. This provides a small boost to all setType calls.
2018-09-29 04:40:04 +02:00
From: Aikar <aikar@aikar.co>
Date: Fri, 28 Sep 2018 22:27:33 -0400
Subject: [PATCH] Don't recheck type after setting a block
The server does a "Did my update succeed" check after setting
a blocks data to a chunk.
However, writes can not fail outside of a hard error or a
a race condition from multiple threads writing, which is
not something that should ever occur on the server.
So this check is pointless, as if it did occur, the server would
be having data corruption issues anyways.
This provides a small boost to all setType calls.
diff --git a/src/main/java/net/minecraft/server/Chunk.java b/src/main/java/net/minecraft/server/Chunk.java
Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
index 0b2d9a05f4..8da88e1c3a 100644
Don't recheck type after setting a block The server does a "Did my update succeed" check after setting a blocks data to a chunk. However, writes can not fail outside of a hard error or a a race condition from multiple threads writing, which is not something that should ever occur on the server. So this check is pointless, as if it did occur, the server would be having data corruption issues anyways. This provides a small boost to all setType calls.
2018-09-29 04:40:04 +02:00
--- a/src/main/java/net/minecraft/server/Chunk.java
+++ b/src/main/java/net/minecraft/server/Chunk.java
Disable use of Locks on main thread for DataPaletteBlock This should greatly improve performance by using a No Op lock while on the main thread. Vanilla always had a write lock on write operations, but we added a Read Lock during Async Chunks to make concurrent writes non fatal for Async Chunks. This means we added on a bunch of over head to all chunk read operations. This corrects that, as well as disabling the write lock while on main thread. It is a general rule that you do not touch a chunk async once it is loaded into the world, as we never had locks on the chunk before 1.13 even. So once we are on main, we don't expect concurrent access to begin with, so we don't need the write locks either.
2018-10-03 04:29:31 +02:00
@@ -574,7 +574,7 @@ public class Chunk implements IChunkAccess {
Don't recheck type after setting a block The server does a "Did my update succeed" check after setting a blocks data to a chunk. However, writes can not fail outside of a hard error or a a race condition from multiple threads writing, which is not something that should ever occur on the server. So this check is pointless, as if it did occur, the server would be having data corruption issues anyways. This provides a small boost to all setType calls.
2018-09-29 04:40:04 +02:00
this.world.n(blockposition);
}
- if (chunksection.getType(i, j & 15, k).getBlock() != block) {
+ if (false && chunksection.getType(i, j & 15, k).getBlock() != block) { // Paper - don't need to recheck this - this would only fail due to non main thread writes which are not supported
return null;
} else {
if (flag1) {
--
2.19.0
Reference in a new issue Copy permalink