Performance

Every Yuneta release is measured before it is tagged, and a release that moves a lot of code ships a performance report. This page keeps the history: the trend of the main figures, report after report, and a link to each report.

Two kinds of figures are kept:

• A/B figures. The same benchmark, built with the module of the new release and with the module of the release before, the two binaries run alternately on one machine. They say what the release changed. A change inside the spread of its rounds is noise, and it is called noise. A study compares the release with the last release that has a study, never with a tag nobody measured. When releases without a study sit between the two, the tags between them are built too, and a figure that got slower is measured on each of them until the release (and, where it is cheap, the commit) where it appeared is named.

• Absolute figures. The benchmarks run on the build of the release at tag time. They say what one machine does with the release: records stored per second, messages per second, what one operation costs.

A figure that got slower is never left out. It is shown with its reason, as the CHANGELOG states it: most are the price of a guarantee (a file that survives a power cut, a record that reaches the disk before a command runs), kept by decision.

Reports¶

The report is one self-contained page (no script, no external file). GitHub shows it as source code; the “view” link renders it. How a report is made, and the schema of its .json, are in performance/reports/README.md.

The trend¶

The C_TREEDB open of 7.25.5 compares two separate runs: 7.25.4 (medians of an earlier run) and 7.25.5 as shipped (the tag-time run). Every other point of the table comes from one alternated A/B run. Each point is the figure its own report measured, so two neighbouring points come from two runs, days apart: the A/B of 7.25.20 measured 7.25.5 again, the A/B of 7.25.21 measured 7.25.20 again, the A/B of 7.25.22 measured 7.25.21 again, the A/B of 7.26.0 measured 7.25.22 again, the A/B of 7.26.9 measured 7.26.0 again (7.26.1 to 7.26.8 shipped no report; it was redone after the release), the A/B of 7.27.0 measured 7.26.9 again, the A/B of 7.27.5 measured 7.27.0 again (7.27.1 to 7.27.4 shipped no report; 7.27.5’s was written the day after the release), the A/B of 7.27.7 measured 7.27.5 again, with 7.27.6 (no report) in the same rotation, the A/B of 7.27.10 measured 7.27.7 again (7.27.8 and 7.27.9 changed no measured code), the A/B of 7.27.11 measured 7.27.10 again, the A/B of 7.28.0 measured 7.27.11 again (7.27.12 to 7.27.21, lite releases of the agent and the controlcenter, are inside it), the A/B of 7.28.2 measured 7.28.0 again (7.28.1, the agents’ pid file, is inside it), the A/B of 7.28.4 measured 7.28.2 again (7.28.3, the stop of the agent, is inside it), the short A/B of 7.28.5 measured 7.28.4 again, only the figures of the treedb and of the inter-yuno events, and the short A/B of 7.28.8 measured 7.28.5 again, only the inter-yuno events (7.28.6 and 7.28.7 changed no measured code), the A/B of 7.29.0 measured 7.28.8 again (7.28.9 to 7.28.11 shipped no study and are inside it), the A/B of 7.29.2 measured 7.29.0 again (7.29.1 changed no C of the libraries or yunos, only a comment in helpers.c and a new test), the A/B of 7.29.3 measured 7.29.2 again, and the A/B of 7.30.0 measured 7.29.3 again, pinned to one CPU for the first time; their figures are in the sections below. Between two such reports a figure can move by a few percent with no change of the code (the master open of 7.25.20 measured 78.2 ms in its own report and 82.4 ms in the A/B of 7.25.21, another day): read a trend against the A/B of its report.

| Figure | Unit | 7.25.4 | 7.25.5 | 7.25.20 | 7.25.21 | 7.25.22 | 7.26.0 | 7.26.9 | 7.27.0 | 7.27.5 | 7.27.7 | 7.27.10 | 7.27.11 | 7.28.0 | 7.28.2 | 7.28.4 | 7.28.5 | 7.29.0 | 7.29.2 | 7.29.3 | 7.30.0 | |--------|------|--------|--------|---------|---------|---------|--------|--------|--------|--------|--------|---------|---------|--------|--------|--------|--------|--------|--------|--------| | Appends per second (test_topic_pkey_integer, 4 link layouts) | appends/s | 220,120 | 221,588 | 226,720 | 225,883 | 224,185 | 223,864 | 223,770 | 229,502 | 226,311 | 232,605 | 225,186 | 228,739 | 422,850 | 434,385 | 422,318 | - | 430,866 | 429,111 | 419,306 | 430,594 | | Open a store as master, 20 000 md2 files (perf_timeranger2) | ms | 92.5 | 80.8 | 78.2 | 81.9 | 79.6 | 81.9 | 79.9 | 82.2 | 81.1 | 78.8 | 79.3 | 79.0 | 77.4 | 76.5 | 81.8 | - | 78.5 | 76.0 | 77.1 | 79.7 | | A tm query of one minute of a key | ms | 12.7 | 7.4 (migrated) | 7.35 | 7.66 | 7.47 | 12.8 (every row) | 12.5 | 12.8 | 13.2 | 12.9 | 13.2 | 12.9 | 12.9 | 13.0 | 13.4 | - | 12.9 | 12.9 | 12.6 | 12.7 | | treedb: update a node in memory (perf_tr_treedb) | us | 3.92 | 2.92 | 2.32 | 2.32 | 2.41 | 2.49 | 2.29 | 2.46 | 2.36 | 2.36 | 2.37 | 2.43 | 1.14 | 1.14 | 1.22 | 1.16 | 1.18 | 1.17 | 1.18 | 1.14 | | treedb: update a node and save it | us | 11.75 | 10.81 | 7.66 | 7.77 | 7.75 | 7.80 | 7.48 | 7.84 | 7.62 | 7.59 | 7.70 | 7.90 | 4.05 | 4.07 | 4.25 | 4.10 | 4.19 | 4.27 | 4.36 | 4.11 | | treedb: link or unlink two nodes | us | 11.27 | 11.09 | 8.65 | 8.71 | 8.63 | 8.65 | 7.54 | 7.76 | 7.48 | 7.38 | 7.58 | 7.94 | 4.59 | 4.61 | 4.81 | 4.70 | 4.59 | 4.72 | 4.78 | 4.70 | | C_TREEDB: open 40 treedbs whose schema did not change (perf_c_treedb) | s | 1.84 | 0.649 | 0.318 | 0.340 | 0.333 | 0.335 | 0.359 | 0.383 | 0.374 | 0.331 | 0.344 | 0.357 | 0.256 | 0.253 | 0.325 | 0.266 | 0.267 | 0.272 | 0.269 | 0.253 | | One agent audit record of 300 bytes (perf_rotatory) | ns | 6,194 | 554 | 572 | 593 | 568 | 570 | 579 | 578 | 573 | 572 | 559 | 564 | 564 | 558 | 603 | - | 567 | 571 | 577 | 567 | | Event loop echo, 1 KB messages (perf_yev_ping_pong) | K msg/s | 152.2 | 150.5 | 150.1 | 147.1 | 150.5 | 149.0 | 146.5 | 144.9 | 143.1 | 148.3 | 145.3 | 147.1 | 151.4 | 147.6 | 143.2 | - | - | - | - | 148.9 | | TCP echo through the gobj stack (perf_tcp_test4) | round trips/s | 38,706 | 39,344 | 38,191 | 39,715 | 38,292 | 39,511 | 39,034 | 38,744 | 38,301 | 39,107 | 38,877 | 39,035 | 63,478 | 62,915 | 58,567 | - | 61,798 | 60,964 | 61,740 | 64,160 |

A - in the 7.28.5 column is a figure its short study did not measure: no code of 7.28.5 is on its path, and its last measure is the column of 7.28.4. The event loop echo of 7.29.0, 7.29.2 and 7.29.3 is not in the A/B for the same reason: no code of 7.28.9 to 7.29.3 is on its path (the tag-time runs of 7.29.2 and 7.29.3 measured 147.1 and 147.4 K messages per second).

The column of 7.30.0 is the first one measured pinned to one CPU, and the machine at rest: the same binary of 7.29.3 measured 63,841 TCP round trips per second pinned, against 61,740 in its own report. So a move between the columns 7.29.3 and 7.30.0 says little: read the A/B of 7.30.0 below. The event loop echo is back in the A/B: the kernel changed under it.

The appends of 7.25.20, 7.25.21, 7.25.22, 7.26.0, 7.26.9, 7.27.0, 7.27.5, 7.27.7, 7.27.10, 7.27.11, 7.28.0, 7.28.2 and 7.28.4 are measured on whole-release builds (see below), not on the four padded links of 7.25.5. The tm query of 7.25.5 to 7.25.22 is the one of a topic its release had marked; 7.26.0 has no tm markers and reads every row of the key (a topic 7.25.22 had not marked took 402 ms).

What each figure means¶

7.30.0 against 7.29.3¶

7.30.0 is a large release: 45,495 lines added and 4,068 removed in .c and .h over 7.29.3. HTTP gets a parser in linear time with limits, and a server that holds what a peer pipelines instead of cutting it. The auth BFF serves a session only to its Origin. A path that does not fit is never used cut. The date reader is rewritten by its rules. Measured against 7.29.3, the last release with a study, before the tag, with no release between them: 10 rounds, each binary pinned to one CPU, on the machine at rest. This release has a page: 7.30.0.html (rendered).

The prices, each one the cost of a fix:

The gains that the release set out to get:

The time of a header in 7.29.3 grew with the square of its size, with the event loop of the yuno held for every client. By default 7.30.0 refuses a head over 64 KB; the limit was raised for these two rows, to compare the same work. The BFF login loses 6.8 us; 3.1 us are named above (1.4 the queue read by name, 1.2 the head, 0.5 the checks of the tokens and the form), and the rest is spread over the profile, with no function above 0.3 us.

Ten figures moved outside their noise with no change of the code on their path. Each was counted with perf stat:

The same instructions and other cycles: placement. The figures that got faster this way are not claimed. The 0.69% fewer instructions of the TLS echo are spread over the profile, and no function explains them. The secret masking did not change in this release: it moved 3 to 5% in perf_micro, by placement too, and stays linear (11.7 ms per MB). It runs only with a trace on. The yunos are 91 to 120 KB larger (stripped), 0.9 to 1.1%.

perf_http and perf_micro are drivers of this study, linked with the libraries of each release. They are not in performance/c/, so the next study has to write them again to compare these rows.

7.29.3 against 7.29.2¶

7.29.3 is the fixes of a review round and a Modbus master that answers every request. In C: build_path() of gobj-c returns NULL and logs when the path does not fit (every path of timeranger2 is assembled with it), the date reader of gobj-c reads again four more forms, the ids of the lists of a treedb take a long yuno name whole (list_id_yuno() of tr_treedb), and the archive of retention (archive_purged_files()) and the old files of the rotatory check the paths they build. The rest is in modules and yunos no benchmark runs (Modbus, M-Bus, the agent, the controlcenter, archive_keeper, the cloners). Of the library objects, only helpers.c, rotatory.c, timeranger2.c and tr_treedb.c have other machine code. Measured against 7.29.2, the last release with a study, before the tag. The same 47 figures as 7.29.2, 8 rounds, its figures here and in its .json, with no report page of its own.

No price. 46 of the 47 figures stay inside their noise, and no round is left out. One figure moved outside its noise, on code that did not change:

The append path (tranger2_append_record(), append_content(), the in-memory realtime lists) has the same machine code in both releases. Of timeranger2.c only purge_key_files() changed, where archive_purged_files() is inlined. Of helpers.c only build_path() (+52 instructions), the date reader and two functions no append runs changed. In a run of the benchmark (360,000 appends) build_path() is called 82 times, at the opens, and the date reader never. In the binary, 3,003 of the 3,237 functions moved, most by 1,536 or 64 bytes, and 21 of them, none on the append path, to another 64-byte alignment. The appends without a reader, in the same binary, measured -2.37% (t = -2.6), inside their noise; measured again, -0.74% and -0.89%, and +0.20% relinked with the libraries of 7.29.2. The TCP echoes, slower by about 2% in 7.29.2 by placement, are 1.5% faster here (t = 2.2 and 2.7), on the same machine code. The code is the same, so the cause is where the code is placed, not what it does. The yunos are 0 to 4 KB larger (stripped).

7.29.2 against 7.29.0¶

7.29.2 is the fixes of a review round. In C: the permission check of C_AUTHZ no longer takes roles from the client’s kw, the date reader of gobj-c reads again the forms it read before 7.28.5, a text append that a realtime list cannot parse still reaches the lists after it (append_content() of timeranger2), a treedb whose name is too long for the ids of its lists is refused at the open, the websocket reads a short getrandom() to its end, and publish-stats refuses a service name that no service can have. The rest is in yunos and tools no benchmark runs (the agent, the controlcenter, archive_keeper, M-Bus, the cloners). Measured against 7.29.0, the last release with a study, before the tag; 7.29.1 changed no C of the libraries or yunos (a comment in helpers.c and a new test). The same 47 figures as 7.29.0, 8 rounds, its figures here and in its .json, with no report page of its own.

No price. 45 of the 47 figures stay inside their noise. Round 3 of the rotation was slow on both builds at once (the appends 35% slower on both), so it is left out and a ninth round takes its place. Two figures moved outside their noise, both on code that did not change:

The objects on the path of the echoes (C_TCP, C_PROT_TCP4H, C_CHANNEL, C_IOGATE, gobj.c, yev_loop, ytls) have the same machine code in both releases. Only the six objects that 7.29.2 changes differ, and the one function of them on a measured path, append_content(), is 23 instructions shorter. The appends benchmark that runs its loop measured -0.09% (t = -0.1). In the binary of the echo, 17,672 of the 17,880 functions moved by about 700 bytes, and 412 of them to another 64-byte alignment. The TLS echo, -2.68% (t = -2.8), stays inside its noise and moves the same way: -2.18% and -1.24% when measured again, +0.79% relinked with the libraries of 7.29.0. Over the three rotations (28 rounds) the echoes are about 2% slower. The code is the same, so the cause is where the code is placed, not what it does. The yunos are 0 to 8 KB larger (stripped).

7.29.0 against 7.28.8¶

7.29.0 lets retention keep what it takes (tranger2_archive_key_files()), adds the yunos that ship the archive to a backup (archive_sender, archive_keeper), an incremental sha256 to gobj-c, and the certificate of the peer to ytls and C_TCP (mutual TLS). Measured against 7.28.8, the last release with a study: 7.28.9 to 7.28.11 shipped none and are inside the comparison (they changed the date reading of gobj-c, C_WEBSOCKET and C_YUNO). Every benchmark whose binary links that code ran, 47 figures, 8 rounds; the raw event loop and MQTT run none of it. The report: 7.29.0.html (view).

No price. 41 of the 47 figures stay inside their noise. Six moved outside it, all on code that did not change in the measured path:

The yunos are 0.2% larger (stripped): the new code, off the measured paths.

7.28.8 against 7.28.5¶

7.28.8 makes json2gbuf() say when it cannot dump a json whole (it now looks at the result of the dump), stops msg2db freeing the defaults of its schema, and indents the machine trace four spaces per level, formatting its line a third faster. Of that, only json2gbuf() is on the path of a benchmark: it dumps every message between yunos, which perf_ievent runs. The trace runs only with a trace on, and msg2db has no benchmark. So this is a short study: perf_ievent alone, against 7.28.5, the last release with a study (7.28.6 and 7.28.7 changed the controlcenter and the scaffolding tools, which no benchmark runs), before the tag. 8 rounds, its figure here and in its .json, with no report page of its own.

No price. The inter-yuno round trips measured 27,537 per second against 27,881, -1.24% (t = -1.9), inside the noise of their rounds.

7.28.5 against 7.28.4¶

7.28.5 writes again the code of others that the MIT license of the SDK cannot carry: the date reader of helpers.c, the string switch of helpers.h (SWITCHS), run_process2(), copyfile(), replace_string() and the SHA-1 and base64 of the websocket handshake. Two of them are on the path of a benchmark: SWITCHS, which tr_treedb runs, and the handshake, which an inter-yuno connection runs once. So this is a short study: only the benchmarks of the treedb (perf_tr_treedb, perf_tr_treedb_read, perf_c_treedb) and of the inter-yuno events (perf_ievent), 18 figures, against 7.28.4, the last release with a study, before the tag. 8 rounds, its figures here and in its .json, with no report page of its own. The other figures run no changed code; their last measure is the study of 7.28.4.

No price. Every one of the 18 figures stays inside its noise: the largest change is the link or unlink of two nodes, +1.67% (t = 2.4), and the inter-yuno round trips measured +0.28% (t = 0.3).

7.28.4 against 7.28.2¶

7.28.4 changes three things in C. A queue gate (C_QIOGATE) refuses a message its queue cannot save and goes on, instead of aborting its yuno: it checks the free space of its disk once a second. Every yuno reads its memory and the free space of its disks once a second, for its stats. And the controlcenter sends the steps of a stop, a pause or a report at once. None of them is on the path of a benchmark. It is measured against 7.28.2, the last release with a study, before the tag; 7.28.3 (the stop of the agent) is inside it. A fix release: 8 rounds, 12 for the appends and the reads, its figures here and in its .json, with no report page of its own.

No price. Every one of the 50 figures stays inside its noise. One crossed it in the rotation of the study: the TLS echo, +1.87% round trips (t = 3.5, 8 rounds). Run again alone, 7.28.2 and 7.28.4 alternated for 10 rounds, it measured +0.99% (t = 1.0); the changed code is not on its path. The yunos are 4 KB bigger stripped, the controlcenter 12 KB.

This run measured 7.28.2 again, and lower than its own report: 419,617 appends per second against 434,385, the TCP echo 57,933 round trips per second against 62,915, the open of 40 treedbs 0.322 s against 0.253 s. The code is the same, so it is the machine on that day. That is why the trend above has a dip at 7.28.4: read the change of a release against the A/B of its own report, where both sides ran on the same day.

7.28.2 against 7.28.0¶

7.28.2 makes every yuno read its signals again when that read ends while the yuno runs: up to 7.28.1 it went deaf to SIGQUIT and the rest, and only a SIGKILL ended it (read_signals_again() in c_yuno.c). The change runs once per signal. It is measured against 7.28.0, the last release with a study, before the tag; 7.28.1 (the agents’ pid file) is inside it. A fix release: a smaller study (8 rounds, 12 for the appends and the reads), its figures here and in its .json, with no report page of its own.

No price. Every one of the 50 figures stays inside its noise. One crossed it in the rotation of the study: the TCP echo with an append per message, -0.94% (t = -5.3, 8 rounds). Run again alone, 7.28.0 and 7.28.2 alternated for 10 rounds, it measured +0.64% (t = 0.6); the changed code is not on its path. The yunos are the same size (stripped: +0 or +4 KB).

7.28.0 against 7.27.11¶

7.28.0 is a performance round over the whole C SDK, taken from an audit and reviewed commit by commit, and it makes jansson Yuneta’s own JSON library (github.com/artgins/jansson, tag 2.15.1-yuneta.1). It is measured against 7.27.11, the last release with a study, before the tag. The releases between them (7.27.12 to 7.27.21, lite releases of the agent and the controlcenter) changed only c_authz.c in the kernel and are inside the same comparison; no figure got slower, so no tag between them had to be measured on its own. Each release is built with its own jansson: 7.27.11 with upstream v2.15.1 and the old patch (atomic reference counts), 7.28.0 with the fork, built with JANSSON_THREAD_SAFE_REFCOUNT=OFF. The report, with its charts: 7.28.0.html.

No price. 40 of the 50 figures are faster outside their noise; the other ten stay inside it. The event loop alone (perf_yev_ping_pong: io_uring, no gobj, no json) is where it was, +0.5% (t = 1.2): the gain is in the layers above it.

Where the gain comes from. A third build ran in the same rotation: the C code of 7.28.0 with the jansson of 7.27.11 (8 rounds, 12 for the appends and the reads). What it leaves of a gain is jansson’s:

timeranger2 owes most of its gain to jansson: a record is a json, dumped when it is written and parsed when it is read (the dump gathered in a buffer, a short string in one block, the lexer reading runs of plain bytes). The treedb and the network owe most of theirs to the rest of the round: the open of a treedb reads the newest record of each key only and rebuilds its hooks indexed; a publication reads its subscriptions from a C record, and an EV_STATE_CHANGED that nobody would see is not built; a websocket server frame goes in one write. The share is of the time one operation takes.

The rotatory. Two of its figures measured slower in the rotation of the study: the log record +1.0% (t = 3.4) and the audit record with its retention +1.8% (t = 8.0). rotatory.c and the path of a record are the same in both releases (rotatory.o has the same machine code; rotatory_write() moved 7,296 bytes). A controlled rotation of five binaries, 16 rounds, ran 7.27.11, 7.28.0, and the same 7.28.0 relinked with 64, 128 and 192 bytes of pad before the libraries: against 7.27.11 the log record measured +1.45% for 7.28.0 and +0.47%, +0.55% and +0.32% for the moved copies, the audit record with retention +2.16% and +0.74%, +1.06% and +0.06%. The same code moves with its placement: code placement, not code.

The new benchmarks. perf_ievent, perf_mqtt and perf_tr_treedb_read are new in 7.28.0; they were built in the tree of 7.27.11 too, with its allocators, so they have both sides. perf_tr_treedb_read stopped at its own N (8 000) on a build with CONFIG_DEBUG_TRACK_MEMORY (“REACHED MAX_SYSTEM_MEMORY”: the default 64 MB of gbmem); it raises the limit now.

The yunos are 0.3% larger stripped (+29 KB to +51 KB).

7.27.11 against 7.27.10¶

7.27.11 puts the yuno in the ids of a treedb’s lists. A replica names a directory of the store after each id, and the id was unique inside one process only, so every yuno of a realm that read the realm’s authz store as a replica shared one directory. The id is built when a treedb or a topic is opened, never per record. It is measured against 7.27.10, the last release with a study, before the tag. A fix release: its figures are here and in its .json, with no report page of its own.

No price. Every one of the 41 figures stays inside its noise. One figure crossed it in the rotation of the study and was measured again: the BFF logins, -1.69% (t = -3.3, 32 rounds). perf_auth_bff never calls the changed functions (no breakpoint of them is hit under gdb), but the change moved its hot code (the event loop, gobj, llhttp, jansson) 128 bytes. A controlled re-run of 24 rounds rotated three binaries: 7.27.10, 7.27.11, and the code of 7.27.10 relinked with the placement of 7.27.11 (a pad of 120 bytes in tr_treedb.o; 17,258 of 17,926 functions at the addresses of 7.27.11). It measured 7.27.11 +0.08% (t = 0.05). Without one slow round of 7.27.10 (5,888 against ~8,300) it is -1.15% (t = -1.6), and the code of 7.27.10 with the new placement -1.38% (t = -1.8), the same: what moves follows the placement of the code, not the code. Those are the figures of this report.

The treedb operations are 2-7% faster and the C_TREEDB opens 2-3.5% slower, all within their noise (|t| < 1.5): their spread is wide at 8 and 24 rounds. The yunos are the same size (stripped: +4 KB for auth_bff, -4 KB for the agent, 0 for the others).

7.27.10 against 7.27.7¶

7.27.10 gives timeranger2 an append for a record that is already json text, tranger2_append_record_text(), and gobj-c a reader of the members of a json object from its text, json_scan_object_members(), with the verdict of jansson and no node built. It is measured against 7.27.7, the last release with a study, before the tag. 7.27.8 and 7.27.9 changed .c files only in the modbus and mbus modules, which no measured binary links, so they were not built: their measured code is the code of 7.27.7.

What the new append is for: a writer of raw history that receives frames as text (an application’s db_events) parsed each frame whole to read three of its members, and dumped it again to store it. With the text path, on the same machine and with the same SDK, it stores 2.2 times more frames per second (24,736 -> 53,308, 100 000 frames, 4 alternated rounds). On a Xeon E-2386G it holds 20 000 records per second for 10.5 minutes at 55% of one core, ~27.6 us a frame (it was ~42 us); reading three members of a frame of ~1 KB costs 0.75 us there, against 19.85 us for the parse, delete, dump and free of the whole.

No price. The one loss the study found is fixed in the release: before the tag, the json append of test_topic_pkey_integer measured -0.87% appends per second (t = -2.6) and -1.18% with a live reader (t = -2.8) after 48 rounds. An A/B with only timeranger2.c changed placed it in commit 8d7e2a85f, the split of the append in two (-1.6%, t = -3.2; -2.0% with a reader, t = -4.0): append_content() read the system_flag of the topic json a second time on every append. Passing it the flag the append had already read removed it (+0.07%, t = 0.1); every benchmark that appends was measured again with the fix, and those are the figures of this report.

Faster outside the noise, without a change aimed at it: the appends of perf_timeranger2, 600 000 into one key (-2.8% of time, t = -5.8) and 400 000 into 20 000 files (-1.6%, t = -3.5), since the same commit; the cause was not isolated. Four figures sit at the edge of their noise after 24 rounds without crossing it, and their code did not change: the open of a store as a replica and as the master (+1.1%), link or unlink (+1.4%), a tm query (+1.5%). The yunos are 0.08-0.16% larger (stripped, 8-16 KB: the scanner and the text append).

7.27.7 against 7.27.5¶

7.27.7 closes three reviews of the retention of 7.27.5: the bounds of an iterator on a replica whose numbering a purge moved, the order of a purge and the links of its feeds, a base read again after a failure that passes, the reads an rt_disk follower owes after EMFILE, the parts of a multi-key C_TRANGER iterator, tr2list. It is measured against 7.27.5, the last release with a study, before the tag. 7.27.6 changed .c files and shipped no study, so it ran in the same rotation: a figure that moved is placed in the release where it moved.

The 9.2 us split in two, measured with an attribution build of 7.27.7 that reads the start time of the process once (never shipped): 47.7 us, so about 5 us is process_start_time() -- a read of /proc/self/stat, made at every delete to name the moved directory -- and about 4 us the rename(). The start time of a process does not change, so that half can be paid once per process.

Every other figure moved inside its spread (|t| < 3): the read path of the master and of a replica (48 rounds; a page of 1 row on a replica 6.27 -> 6.31 us), the appends (+0.5%), the opens of a store, the treedb writes, the agent audit, the event loop, TCP (+2.4% round trips, t = 2.3, 24 rounds), TLS and the BFF logins. The yunos are 0-0.08% larger (stripped, at most 8 KB).

7.27.5 against 7.27.0¶

7.27.5 gives timeranger2 retention: a store deletes the old files of a key and keeps the g_rowid of every row that stays. This study compares it with 7.27.0, the last release with a study, so it covers 7.27.1 to 7.27.5. It replaces the one written the day after the release against 7.27.4, a release nobody had measured. Each move is placed in the release where it appeared: the read path ran once more on every tag from 7.27.0 to 7.27.5 and on two commits of 7.27.5. It adds the read path of an iterator to the benchmarks (perf_timeranger2 read), because the price of this release is there.

How they were placed, the read phase alone, 24 rounds, every build in one rotation (us per operation):

7.27.1 to 7.27.4 read at 7.27.0’s speed. The check of a replica comes with 83a771089 (the followers hear a purge of old key files); a page of 100 rows moves with bd3fdce51 (tranger2_delete_key_files(), the master side of retention), on the master too. The check stays: skipping it while the replica seems to have missed nothing leaves a window (a signal not yet read from the event queue) in which a read opens a deleted file.

The master’s read path, the appends (+1.1%), the opens of a store, the treedb writes, the agent audit, the event loop, TCP, TLS and the BFF logins moved inside their noise: the gobj and TCP changes of 7.27.2 to 7.27.4 cost nothing measurable. 7.27.1 changed only the external libraries (OpenSSL 3.6.3 -> 3.6.5, PCRE2); both sides here run with those of 1.24, and that change was measured on its own when it shipped (the TLS echo -0.9%, t = -0.6). The yunos are 0.4-0.5% larger than in the 7.27.0 report (stripped, about 50 KB): retention.

7.27.0 against 7.26.9¶

7.27.0 is a hardening release (nineteen more rounds of review): the command parser types every parameter, secrets are masked in more places of the logs, the walks of the gobj tree survive a callback that destroys a child, and a NUL in an id, a pkey2 value, an fkey reference or a string of a record is refused. It holds its speed: 30 of the 31 A/B figures stay inside the noise of their rounds, and the one outside it is a price with its cause.

The saved update moved +3.9% (t = 1.7), inside its noise; the attribution run, 16 quieter rounds, measured +3.6% (t = 4.4) with the checks and -0.4% without them: the same price, about 0.1 us of CPU per write. Everything else moved inside its spread (|t| < 3), the price of 7.26.9 included (the event loop echo that appends every message, +0.7% against 7.26.9). The yunos are 1.3-1.4% larger (stripped, about 140 KB): the masking of secrets, the typed command parser and the new checks.

7.26.9 against 7.26.0¶

7.26.9 is a hardening release (sixteen rounds of review): the kw readers, the names that come from data, two name rules, the logger and what C_NODE accepts from a peer. This study compares it with 7.26.0, the last release with a study, so it covers 7.26.1 to 7.26.9; it replaces the one made at the tag against 7.26.8, a release nobody had measured. Each move is placed in its release, and in its commit where that was cheap, by building the tags and commits between them. One of its changes is a gain: the treedb looks its topics, hooks and fkeys up by key (KWID_GET_BY_KEYS()) instead of formatting a path and splitting it again on every call.

The main append benchmark (test_topic_pkey_integer, 4 link layouts) moved +0.7% (t = 0.6). The price the study at the tag reported and could not trace, the event loop echo that appends every message (-3.9% against 7.26.8), is not there against 7.26.0 (-0.2%, t = -0.2): 7.26.8 had measured high that day. Every other figure moved inside its spread (|t| < 3), the read path of the master and of a replica among them. The binaries are 0.16-0.24% larger (stripped) than in the report of 7.26.0.

7.26.0 against 7.25.22¶

7.26.0 changes how timeranger2 reads and how its followers hear deletes: the md2 rows of a scan are read 1024 at a time with one pread(), and the match condition is parsed once per scan; the tm markers of 7.25.5..7.25.22 are gone, so a tm condition filters every row of any topic; a key delete reaches the rt_disk followers with the master’s delete sequence; and a link in a treedb publishes the relationship (with_link_events on by default), not the parent collapsed whole.

Fixed before the tag: a master that opens a topic makes its delete_seq.json (the record of the delete sequence, which a follower takes as the sign that its master signals each delete in order). Written durably -- a file fsync, a rename and a directory fsync per topic -- it doubled the creation of 10 topics (131.4 -> 258.5 ms) and made the first open of 40 treedbs (400 topics) 55% longer (10.42 -> 16.19 s). It holds 0 and is made again if lost, so it is written NOT durably now: 134.0 ms and 10.33 s, within the noise of 7.25.22 (the 7.26.0 side measured again after the fix, 8 rounds).

Not measured: a key delete on a topic with an rt_disk feed. No benchmark deletes keys under a feed; by construction such a delete writes the record of its sequence first, two fsyncs and a rename more than 7.25.22 did. A topic without feeds pays nothing.

Every other figure moved inside its spread (|t| < 3), on paths that changed or not. The binaries are 0.04-0.15% larger (stripped).

The method: 7.25.22 and 7.26.0 each built from their own tree (a git worktree of the 7.25.22 tag with the same .config and compiler, where only the kernel libraries, the modules, performance/c/ and the three ctest binaries were built), the two binaries of each benchmark run alternately, the order flipped every round, with a sync and a 3 s pause before each run: 8 rounds, 24 for the three timeranger2 ctest binaries. outputs_ext was shared: linux-ext-libs did not change. The treedb figures are CPU time of the process.

What one machine does with 7.26.0¶

The 7.26.0 side of the same run: 8 rounds (24 for the ctest binaries), mean of the rounds, on the machine described below.

7.25.22 against 7.25.21¶

7.25.22 closes two reviews -- of 7.25.21, and of the fixes made for it -- and the open defects of the list it inherited: the agents run as native systemd units; a connection can be dropped from any callback of TLS or TCP without a use of freed memory; a yuno alive but not connected can be killed; the rt_disk followers of timeranger2 hear what they used to lose; C_AUTHZ and the IdP stop handing roles and keys to whoever asks; a stats reset resets.

Four figures moved outside their spread on code that did not change in this release, and none is claimed:

Both releases are built whole, so the code lands at other addresses, which alone moves a figure by a few percent: that is placement, not speed, and it is said with its figure. The binaries are 0.4-0.5% larger (stripped).

The method: 7.25.21 and 7.25.22 each built from their own tree (a git worktree of the 7.25.21 tag with the same .config and compiler, where only the kernel libraries, modules/c/test, performance/c/ and the three ctest binaries were built), the two binaries of each benchmark run alternately, the order flipped every round, with a sync and a 3 s pause before each run: 8 rounds, 24 for the three timeranger2 ctest binaries. outputs_ext was shared: linux-ext-libs did not change.

What one machine does with 7.25.22¶

The 7.25.22 side of the same run: 8 rounds (24 for the ctest binaries), mean of the rounds, on the machine described below.

7.25.21 against 7.25.20¶

7.25.21 is a security and correctness release: credentials are masked in every trace, in every kw the kernel dumps, in the traffic dumps and in view-config; a gbuffer can be marked secret (hidden from the dumps, wiped when it is freed, never serialized); C_TCP and C_TCP_S stop and start again cleanly and count their connections; the rt_disk feeds of timeranger2 hear every delete. None of it is on the paths that run every second at the default trace levels: the masking runs only when a trace prints. On those paths a secret gbuffer costs the test of one flag, and a TCP send one key lookup (the __secret__ flag of EV_TX_DATA).

Nothing got slower beyond the spread of its rounds. Three figures moved outside it, all of them faster, and none is claimed as a gain:

Both releases are built whole, so the code lands at other addresses, which alone moves a figure by a few percent (2.5% on an append, measured for 7.25.5): that is placement, not speed. The main append benchmark, test_topic_pkey_integer, 24 rounds, moved +1.3% (223,031 -> 225,883 appends/s), inside its spread. The binaries are 0.6-0.9% larger (stripped), the code of the masking.

The method: 7.25.20 and 7.25.21 each built from their own tree (a git worktree of the 7.25.20 tag with the same .config and compiler, where only the kernel libraries, modules/c/test, performance/c/ and the three ctest binaries were built), the two binaries of each benchmark run alternately, the order flipped every round, with a sync and a 3 s pause before each run: 8 rounds, 24 for the three timeranger2 ctest binaries. outputs_ext was shared: linux-ext-libs moved from 1.22 to 1.23 in this release, but only in how openresty is downloaded, and no library changed version.

What one machine does with 7.25.21¶

The benchmarks of performance/c/ on the build of 7.25.21 at tag time, 5 rounds; the appends and reads of the ctest binaries are the 7.25.21 side of the A/B run (24 rounds). Mean of the rounds, on the machine described below.

7.25.20 against 7.25.5¶

The fifteen releases between the two reports fixed the agent, the file watcher, the TCP writes, the SWITCHS macro and the masking of secrets. None of them was meant to change speed, and one of them is the largest gain of the round: since 7.25.7 SWITCHS no longer compiles a regular expression each time a switch is entered (it leaked it on every return from a case, commit 3e8ff0508). tr_treedb switches on the type of every column, so every treedb write paid a regcomp(".*") and a regfree; tr_treedb.c and c_treedb.c did not change between the two releases.

Nothing got slower beyond the spread of its rounds. The closest, tm_build_appends (600 000 appends to one key, 1,632 -> 1,691 ms, +3.6%, at the edge of the spread), runs append code that is the same in both releases: timeranger2.c changed only in its rt-disk rescan. Both releases are built whole, so the code lands at other addresses, which alone moves an append by up to 2.5% (measured for 7.25.5); the main append benchmark, test_topic_pkey_integer, 24 rounds, moved +0.3%.

The method: 7.25.5 and 7.25.20 each built whole from their own tree (a git worktree of the tag for 7.25.5; the same .config, compiler and external libraries), the two binaries of each benchmark run alternately, the order flipped every round, with a sync and a 3 s pause before each run: 8 rounds, 24 for the three timeranger2 ctest binaries.

What one machine does with 7.25.20¶

The 7.25.20 side of the same run: 8 rounds (24 for the ctest binaries), mean of the rounds, on the machine described below.

7.25.5 against 7.25.4¶

The prices of 7.25.5, and what each one buys:

Every A/B of 7.25.5, change by change, with its rounds and spread, is in performance/c/README.md and in the CHANGELOG (“Performance, against 7.25.4”).

What one machine does with 7.25.5¶

Measured at tag time on the build of 7.25.5: 5 rounds (3 for perf_c_treedb and perf_auth_bff), mean of the rounds. One process; the event loop runs on one core, and Yuneta scales by running one yuno per core.

TLS with OpenSSL costs 24% of the round trips of plain TCP through the gobj stack (29,166 against 38,587). mbedTLS is not built on the measuring machine, so its figures are not in the report.

How the figures are measured¶

• The machine. One laptop, the same for every report until a report says otherwise: an Acer Nitro AN517-53 with an 11th Gen Intel Core i7-11370H (4 cores, 8 threads, up to 4.8 GHz), 31 GiB of RAM, a Samsung 990 PRO NVMe with ext4, Linux 7.0.0-34-generic, Ubuntu 26.04.1 LTS, glibc 2.43, gcc 15.2.0. Absolute figures compare only between reports of the same machine.

• The build. RelWithDebInfo (-O2 -g), gcc, fully static, OpenSSL, with CONFIG_DEBUG_TRACK_MEMORY on (every allocation is tracked).

• A/B. The module of the old release is compiled with the headers of the new one and linked before the same libraries; the two binaries run alternately, with a sync and a pause before each run. For timeranger2 the modules are padded to one size and linked four times at four addresses, because the address of the libraries alone moves an append by up to 2.5%. That is the A/B of 7.25.5. The A/B of 7.25.20 and of 7.25.21 builds each release whole from its own tree and runs the two binaries alternately, the order flipped every round: simpler, and blind to a change under ~2.5% on an append, which it says where it matters.

• Pinned. From 7.30.0 on, each binary runs pinned to one CPU with taskset.

• Tag time. The benchmarks of performance/c/, in rounds, on the build of the release.

The benchmarks themselves are described in Benchmarks & Stress Tests.