this provides some performance improvement (although it's difficult to measure because of cache).
this does mean that we read some garbage data during chunk reads, but it's less costly than hitting the disk twice.
I was unaware that fseek actually makes a syscall which is rather costly, which became painfully obvious during large world conversions on PM4.
On average this problem appeared to be adding about 5ms to the load time for a newly loaded region, which is insanely expensive.
In the old days, we used to try to correct this problem by adjusting the region header to match the
length found at the start of the chunk payload. However, this has a very good chance to cause corruption
of other chunks, since we can't do any fast overlap checks (an upsize might cause the chunk's alloocated
area to overlap into another one, causing corruption when either chunk's space gets written to).
This corruption risk has become more problematic since the
introduction of region garbage sector reuse, since a broken location
header could cause chunks to trash each others' saved data.
In addition, if there is a length mismatch, there's a good chance that the oversized chunk itself will
already be corrupted, so we'd just fail trying to decompress it later on.
So, instead of trying to fix this automatically, we bail and hope this doesn't occur often enough for
users to get upset, and allow external offline tools to attempt to repair the mess instead.
commit 1f42169f0f929958f7d68a68f194c6f3492b7eb4
Author: Dylan K. Taylor <odigiman@gmail.com>
Date: Mon Dec 14 21:23:44 2020 +0000
... install it in the right fucking place
commit d2a88abeda5fa937d3f508c4e0300a949af97846
Author: Dylan K. Taylor <odigiman@gmail.com>
Date: Mon Dec 14 21:14:21 2020 +0000
Build PHP using system libraries to reduce rebuild time
