Is your feature request related to a problem?
Item Frame Map Cursor Updates are laggy, sometimes taking in 5-13% of our server tick. In the past, a PR was added to allow them to be configurable (item-frame-cursor-update-interval). However, when maps are used as decoration (as in our server which as 11 thousand) they cause immense lag regardless.
These updates are also misnamed- while they are probably intended to update the cursors on maps, they are also used to send the map canvas as well, so turning these updates off would mean that no map canvas are sent to the client. This also means that our server rather wants to turn the interval down, as this allows these maps to load faster, without any visual errors.
The lag is primarily caused by WorldMapItem#getMapId, which for some odd reason seems to carry a significant overhead despite just accessing the NBT of the item stack.
Describe the solution you'd like.
There is one optimization I know that can be added to make this section of the code:
Cache Map ID in the Item Frame Entity Class
ItemFrame already has a nice method where the map id can be cached and placed into the entity itself (onItemUpdate), which runs any time the item stack is changed or loaded on/with the entity. This cached integer would range from [0, +infinity), with non-map-items being able to set the map id to -1 as that is not a valid map id.
As you can see in the method, this primarily would save the overhead created from calling #getMapId every few ticks to only needing it to be cached. This also helps a small overhead created by accessing the item stack saved inside the synced entity data.
Not sure what else can be done about this, but I talked to @Warriorrrr who wrote the former PR and he might have some other things to add. There's probably some nitty gritty stuff inside how the update packet is created.
Describe alternatives you've considered.
We aren't hitting 50 mspt yet, but since I estimate that we will have 4 times as many item frame maps as we currently do, I hope to avoid this limit as much as possible so we don't have to switch machine or possibly limit our player counts.
Other
Is your feature request related to a problem?
Item Frame Map Cursor Updates are laggy, sometimes taking in 5-13% of our server tick. In the past, a PR was added to allow them to be configurable (item-frame-cursor-update-interval). However, when maps are used as decoration (as in our server which as 11 thousand) they cause immense lag regardless.
These updates are also misnamed- while they are probably intended to update the cursors on maps, they are also used to send the map canvas as well, so turning these updates off would mean that no map canvas are sent to the client. This also means that our server rather wants to turn the interval down, as this allows these maps to load faster, without any visual errors.
The lag is primarily caused by WorldMapItem#getMapId, which for some odd reason seems to carry a significant overhead despite just accessing the NBT of the item stack.
Describe the solution you'd like.
There is one optimization I know that can be added to make this section of the code:
Cache Map ID in the Item Frame Entity Class
ItemFrame already has a nice method where the map id can be cached and placed into the entity itself (onItemUpdate), which runs any time the item stack is changed or loaded on/with the entity. This cached integer would range from [0, +infinity), with non-map-items being able to set the map id to -1 as that is not a valid map id.
As you can see in the method, this primarily would save the overhead created from calling #getMapId every few ticks to only needing it to be cached. This also helps a small overhead created by accessing the item stack saved inside the synced entity data.
Not sure what else can be done about this, but I talked to @Warriorrrr who wrote the former PR and he might have some other things to add. There's probably some nitty gritty stuff inside how the update packet is created.
Describe alternatives you've considered.
We aren't hitting 50 mspt yet, but since I estimate that we will have 4 times as many item frame maps as we currently do, I hope to avoid this limit as much as possible so we don't have to switch machine or possibly limit our player counts.
Other