From 29221af45101db8048bce3bdaacff41dc16b9b48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Reynir=20Bj=C3=B6rnsson?= Date: Fri, 19 Apr 2024 14:45:09 +0200 Subject: [PATCH] Add note about old lexifi post --- articles/miragevpn-performance.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/articles/miragevpn-performance.md b/articles/miragevpn-performance.md index 2d27eed..5c76186 100644 --- a/articles/miragevpn-performance.md +++ b/articles/miragevpn-performance.md @@ -40,7 +40,7 @@ We also re-read our code and used the Linux utility [`perf`](https://perf.wiki.k ## Takeaway of performance engineering The learnings of our performance engineering are in three areas: -- Formatting strings is computational expensive -- thus if in an error case a hexdump is produced of a packet, its construction must be delayed for when the error case is executed (we have [this PR](https://github.com/robur-coop/miragevpn/pull/220) and [that PR](https://github.com/robur-coop/miragevpn/pull/209)). Alain Frisch wrote a nice [blog post](https://www.lexifi.com/blog/ocaml/note-about-performance-printf-and-format/#) at LexiFi about performance of `Printf` and `Format`. +- Formatting strings is computational expensive -- thus if in an error case a hexdump is produced of a packet, its construction must be delayed for when the error case is executed (we have [this PR](https://github.com/robur-coop/miragevpn/pull/220) and [that PR](https://github.com/robur-coop/miragevpn/pull/209)). Alain Frisch wrote a nice [blog post](https://www.lexifi.com/blog/ocaml/note-about-performance-printf-and-format/#) at LexiFi about performance of `Printf` and `Format`[^lexifi-date]. - Rethink allocations: fundamentally, only a single big buffer (to be send out) for each incoming packet should be allocated, not a series of buffers that are concatenated (see [this PR](https://github.com/robur-coop/miragevpn/pull/217) and [that PR](https://github.com/robur-coop/miragevpn/pull/219)). Additionally, not zeroing out the just allocated buffer (if it is filled with data anyways) removes some further instructions (see [this PR](https://github.com/robur-coop/miragevpn/pull/218)). And we figured that appending to an empty buffer nevertheless allocated and copied in OCaml, so we worked on [this PR](https://github.com/robur-coop/miragevpn/pull/214). - Still an open topic is: we are in the memory-safe language OCaml, and we sometimes extract data out of a buffer (or set data in a buffer). Now, each operation lead to bounds checks (that we do not touch memory that is not allocated or not ours). However, if we just checked for the buffer being long enough (either by checking the length, or by allocating a specific amount of data), these bounds checks are superfluous. So far, we don't have an automated solution for this issue, but we are [discussing it in the OCaml community](https://discuss.ocaml.org/t/bounds-checks-for-string-and-bytes-when-retrieving-or-setting-subparts-thereof/), and are eager to find a solution to avoid unneeded computations. @@ -51,3 +51,5 @@ To conclude: we already achieved a factor of 25 in performance by adapting the c Don't hesitate to reach out to us on [GitHub](https://github.com/robur-coop/miragevpn/issues), or [by mail](https://robur.coop/Contact) if you're stuck. We want to thank [NLnet](https://nlnet.nl) for their funding (via [NGI assure](https://www.assure.ngi.eu/)), and [eduVPN](https://eduvpn.org) for their interest. + +[^lexifi-date]: It has come to our attention that the blog post is rather old (2012) and that the implementation has been completely rewritten since then.