Preliminary results show that the extension code is sped up by an order of magnitude by being written in optimized native code rather than emulated BPF code. For the example used earlier, described in Figures 1-4, executed on a 333MHz Celeron CPU and entirely in-cache, the native code took an average of 0.130, while the BPF code took an average of 1.328. This is consistent with the PCC project's results and with this project's expectations. This is the recurring cost and is the cost that executes synchronously with the performance-critical part of the system (packet reception from the network in real-time), so an order of magnitude speedup is very helpful.
The more important result for this project is the performance of the prover itself. Related works, such as PCC, did not appear to make available solid information about the performance of their provers, but consistently indicated that their speed and memory consumption were fairly high (with the justification that that was a one-time cost). In order to be practical for inclusion into an operating system's kernel, the run-time and memory requirements for a prover must still be reasonably small. On the example used, the prover developed for this project took an average of 938 of execution time, and required 29,964 bytes of heap space above 17,152 bytes of program (with a small amount of stack space also required). This is for a rough, un-optimized implementation. All of those requirements could probably be decreased linearly, but not by an order of magnitude. Implementing more complex reasoning in the prover might increase those costs.