Describe the bug
During reading the MultiBlockChangeInfo of a MultiBlockChangePacket the most time is spent getting the currentPermGenUsage. In my case this makes up 15% of the "Runnable" time of the main spigot server thread (around 10% with waiting between ticks during the complete server runtime).

To Reproduce
Steps to reproduce the behavior:

1. Register an (synchronous) MultiBlockChangePacket-Listener and get the StructureModifier for the MultiBlockChangeInfo
2. Start a profiler to measure the time spent in different functions
3. Produce a whole bunch of MultiBlockChangePackets (e.g. with some massive Redstone construction)
4. Look in the profiler and see the usage of MultiBlockChangePackets

Expected behavior
The MultiBlockChangePacket-Listener should not spend most of its time in java.lang.Management.ManagementFactory.getMemoryPoolMXBeans().

Screenshots

Version Info
https://pastebin.com/MewW3wFP

Additional context
My players fight with large self-built tnt redstone cannon constructions against each other and don't like it if everybody with a world downloader plugin (or similar) can simply copy their redstone constructions - so the world has to be filtered. I recently profiled a whole fight - inclusive server start, players joining (around 10 players during the heavy workloads), fight and stopping. During this, the above screenshotted profile was created. It should be considered if the getMemoryPoolMXBeans() call is really needed and if it is needed every time. In my case it's the most time consuming single task the server does in the main thread.

If required, the source code which calls the MultiBlockChangeInfo Structure Modifier can be found under https://steamwar.de/devlabs/SteamWar/FightSystem/src/branch/master/FightSystem_Main/src/de/steamwar/fightsystem/utils/TechHider.java line 107 - 142.

I think this was fixed a while ago (#876)

Give the latest dev build a try: https://ci.dmulloy2.net/job/ProtocolLib

Sr for the late reply. Tested it with the newest build and the issue seems fixed.