ideally this should of never mattered, as it will only
be hit if you teleport out of an unloaded chunk...
But apparently some people are triggering this.
See #1223
Spigot had code that returned early in chunk add/remove methods.
This was causing our code added to set current chunks and counts to
be skipped over if the entity was default not persistent but made persistent.
This was the source of many issues
Fixes#1208
This enables us a fast reference to the entities current chunk instead
of having to look it up by hashmap lookups.
We also store counts by type to further enable other performance optimizations in later patches.
At the time this was re-added, there was concern around how the JIT
would handle the system property that enabled it.
This shouldn't be a problem, and as such we no longer need to block
access to it.
The Vanilla Method Profiler will not provide much to most users however
there is no harm in providing it as an option. For most users, the
recommended and supported method for determining performance issues with
Paper will continue to be Timings.
This simply provides the base API to create the objects. Further commits will come that adds
adds usage of this API to existing GameProfile based API's, as well as new API's.
Instead of overriding add within the queue, never add runnables to the
queue if the light queue is disabled.
This change is made to make timings reports and stacktraces less
confusing for administrators, who prior to this change, would have seen
the lighting queue referenced in both, regardless of whether or not it
was enabled.
This change should not affect performance, nor is it made with the
intent to.
Spigot, by default, disables several mechanisms around how chunks are
lit, if ever, which has forced them to always send chunks before vanilla
would consider them ready to send, causing for lots of issues around
lighting glitches.
Shamefully, the amount of work to relight chunks can be detremental
to some servers, meaning that forcibily disabling light updates can
cause major performance issues.
as such, we make a compromise; if this "feature" is disabled, we will
only send chunks which are actually ready to be sent, otherwise, we
will always send chunks.
