Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi.
I identified a performance bottleneck in
NetworkPacket
being 9376 bytes long! This amount was mainly contributed byetherparse::NetHeaders
enum includingetherparse::Ipv{4,6}Extensions
, that are 1032 and 9236 bytes long respectively, while not being used anywhere in this project.Since
NetworkPacket
is quiet often passed around in memory and it's so heavy that it causedmemmove
to kick in ref. This resulted in a significant amount of time being spent inmemmove
even for smaller payloads.So excluding the ip extensions' data from the
NetworkPacket
resulted in 6000% performance gain for decoding small packets (64 bytes) and 200% gain for decoding large packets (65k bytes). The gain is decreasing because currently all the payload stored inNetworkPacket
is still being copied to aVec
.Flamegraph for `decode_mtu_64` benchmark without the optimization
Flamegraph for `decode_mtu_64` benchmark with the optimization
Also the way I wrapped
criterion
to allow it to benchmark private fields isn't really conventional, so feel free to discard associated commit if that doesn't fit this project.