New async nbt cache #347
New async nbt cache #347
Conversation
what? |
there are diff problems, missing |
|
Ah ok. I didn't understand what you meant lmao. |
There was a problem hiding this comment.
LGTM, just needs that info in the patch commits, and proper commits when you change a section of code (as @MrIvanPlays said). But either than that, since it's been in a production environment, I see no reason as to why it shouldn't get merged!
MrIvanPlays
force-pushed
the
ver/1.16.5
branch
2 times, most recently
from
c232045
to
ecf1662
Compare
duplexsystem
force-pushed
the
ver/1.16.5
branch
from
656de35
to
372911f
Compare
There was a problem hiding this comment.
Along with @HookWoods using this patch privately in production for a while, I've been using it for the past 2 days on my server without any issues whatsoever. Seems good to merge into staging/1.16.5
Titaniumtown
added
the
Ready for Review
* add config for sand duping (#352) * Lithium: cache chunk gen sea level (#349) based off: CaffeineMC/lithium-fabric@a55cfd1 * PaperPR: Inline shift fields in EnumDirection (#350) * Introducing: Yatoclip (#360) * New async nbt cache (#347) * update pom * whoops * Try to address path issue and improve Jenkins build speed * Detailed lag and crash reports (#369) Added "Suspected Plugins" to Watchdog and crash reports * Drop sand duping * Add branch specific versions * Remove copyright * Revert mysql-connector-java version bump * Small fixes * More detailed lag and crash reports * Don't use branch information when generating metadata * Fix Jenkins Builds version command * Fixup patches * Fix patch notes * Pull Request compatibility for branch detection * Fix Pull Request compatibility for branch detection * Set context classloader before launch * Inject server jar to SystemClassLoader before launch * Try fix compile in java8 * Run tests on CodeMC and Github Actions Co-authored-by: Simon Gardling <Titaniumtown@gmail.com> Co-authored-by: Zoe <duplexsys@protonmail.com> Co-authored-by: Hugo Planque <12386279+HookWoods@users.noreply.github.com>
The goal of this pr is to reduce I/O operations from the main thread while saving player data and also to avoid too many I/O operations while reading NBT Player file by using a cache (Which start to delete the oldest data when there is too much player compared to the map size)
I don't know if the map implementation is the best method or using a LRU system would be better