You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a constant stream of memory allocations coming from networking layer in MP games. These allocations can be traced to NetMessage instances, each of which has a vector<uint8_t> to store the message payload.
This behavior can be easily observed by profiling heap allocations with any applicable tool (for example: perf, HeapTrack, or MSVC's builtin profiling tools) while running a WZ process.
It probably makes sense to provide a custom allocation strategy for the message payload data (e.g. a memory pool-based allocator/arena allocation or dynamically growing circular buffer).
Also, there's a chance that some NetMessage copies can be avoided (but I'm not yet sure about that), so an additional investigation should be conducted to either prove or disprove that.
The text was updated successfully, but these errors were encountered:
There's a constant stream of memory allocations coming from networking layer in MP games. These allocations can be traced to
NetMessage
instances, each of which has avector<uint8_t>
to store the message payload.This behavior can be easily observed by profiling heap allocations with any applicable tool (for example:
perf
, HeapTrack, or MSVC's builtin profiling tools) while running a WZ process.It probably makes sense to provide a custom allocation strategy for the message payload data (e.g. a memory pool-based allocator/arena allocation or dynamically growing circular buffer).
Also, there's a chance that some
NetMessage
copies can be avoided (but I'm not yet sure about that), so an additional investigation should be conducted to either prove or disprove that.The text was updated successfully, but these errors were encountered: