Timings currently account for the time spent sending and encoding a packet, as well as DataPacketSendEvent. However, for some packets, the overhead isn't in the encoding of the packet, but rather in the initial construction.
This is most easily observed with CraftingDataPacket, but is also seen with InventorySlotPacket and InventoryContentPacket. The time spent converting core items to network itemstacks ends up being accounted by some generic parent timer.
It's not clear where else this might be a problem, which is precisely why we need timings for this.
Alternative methods
We could just add random timers for paths we suspect are hot, but I think a system that covers all packets makes more sense.
dktapps
commented
1 year ago
Description
Timings currently account for the time spent sending and encoding a packet, as well as DataPacketSendEvent. However, for some packets, the overhead isn't in the encoding of the packet, but rather in the initial construction.
This is most easily observed with CraftingDataPacket, but is also seen with InventorySlotPacket and InventoryContentPacket. The time spent converting core items to network itemstacks ends up being accounted by some generic parent timer.
It's not clear where else this might be a problem, which is precisely why we need timings for this.
Alternative methods
We could just add random timers for paths we suspect are hot, but I think a system that covers all packets makes more sense.