I'm looking at refactoring the packet parsing and capture utilities within knock_rs but wanted a way to test the performance before I changed anything. Turns out the parsing is definitely not a restriction on knock_rs' performance. 110 ns to parse a packet... ya definitely not slowing anything down.
Although rust now has the ability to run benchmarks within the std library, criterion has some default features which make it hard to pass up. The ability to get graph printouts of the benchmark, with comparison to the previous run, is great for testing out changes to the code base.
This is the default printout that criterion provides, slightly modified to fit with the styling of this site. Nonetheless this is great!
The packet parser and low level packet capture libraries have been changed. Knock_rs no longer relies on pnet and instead uses rust pcap .
The data below has been updated and the time to parse a packet has been reduced by more than half, from around a 110 ns to just 40-45 ns. The speed of parsing wasn't an issue with pnet but it is a very heavy library, and this not only improved performance, compile time is now much shorter.
It also gave me the excuse to build a packet parsing library of my own . Which was an interesting project. My implementation is much smaller with not nearly as much support as the whole of pnet, but works for my use case and I'll continue to add support for more protocols and packet types as needed.
Lower bound | Estimate | Upper bound | |
---|---|---|---|
Slope | 43.315 ns | 43.613 ns | 43.941 ns |
R² | 0.9235409 | 0.9279888 | 0.9225954 |
Mean | 43.178 ns | 43.457 ns | 43.761 ns |
Std. Dev. | 1.1127 ns | 1.5129 ns | 1.9740 ns |
Median | 42.975 ns | 43.308 ns | 43.504 ns |
MAD | 1.0662 ns | 1.4026 ns | 1.6209 ns |
|
|
Lower bound | Estimate | Upper bound | ||
---|---|---|---|---|
Change in time | -63.135% | -62.615% | -62.126% | (p = 0.00 < 0.05) |
The plot on the left shows the probability of the function taking a certain amount of time. The red curve represents the saved measurements from the last time this benchmark was run, while the blue curve shows the measurements from this run. The lines represent the mean time per iteration. Click on the plot for a larger view.
The plot on the right shows the two regressions. Again, the red line represents the previous measurement while the blue line shows the current measurement.
See the documentation for more details on the additional statistics.