From 97a366e8b7c540b246c7bf9d04625526cbdc88ba Mon Sep 17 00:00:00 2001 From: cirakg Date: Mon, 19 Oct 2026 15:27:37 +0200 Subject: docs: document the storage format and record M3 results; bump to 0.3.0 Co-Authored-By: Claude Opus 5.5 --- docs/PERFORMANCE.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'docs/PERFORMANCE.md') diff --git a/docs/PERFORMANCE.md b/docs/PERFORMANCE.md index daab3c2..fbc9709 100644 --- a/docs/PERFORMANCE.md +++ b/docs/PERFORMANCE.md @@ -25,6 +25,22 @@ The targets are in [README section 18](../README.md#18-performance-budgets). Thi ## Results +### M3, 2026-10-19 (version 0.3.0, storage) + +`test/BenchTest.mc` with an in-memory store, simulator in Docker, Forerunner 70 profile: + +| Operation | Time | Notes | +| --- | --- | --- | +| Read 20 entry headers | 6.8 ms | 0.34 ms per header, mostly TLV decoding in Monkey C | +| Open one entry (verify + decrypt) | 1.05 ms | Device-key entry | +| Add and remove one entry | 1.4 ms | Seal, two metadata writes | + +Record sizes: 239 bytes for a typical OTP entry, 208 for a short code, 4,279 for the largest allowed payload. + +`make perf` and `make memtest`: in-app start-up 1 to 6 ms, and launch to first frame 10.5 s, unchanged. Memory after the first frame rose to 4.0 % (768 KB watches) and 5.9 % (Forerunner 255S), because the debug program is larger; the app doesn't open the vault yet. The signed package for 72 products is 2.5 MB. + +Consequence for M4: reading 150 headers would take about 50 ms in the simulator, and on the watch probably many times that. The list will cache headers and read only the visible rows when it opens, instead of reading all of them at start-up. + ### M2, 2026-10-18 (version 0.2.0, crypto and OTP primitives) `test/BenchTest.mc`, simulator in Docker, average per call (identical within noise on all four test devices): -- cgit v1.2.3