1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
//! W14.3: what does one `assert_edge` actually pay for, and how much of it was
//! the actor forgetting what it knew a moment ago?
//!
//! Review C-6 counts three round trips on the single-edge write — a `branches`
//! query for the lineage shape, a compile of the overlap guard, and a compile of
//! `INSERT_LINK` — and says they are "a visible fraction" of the ~0.8 ms
//! transaction floor. A fraction is not a number, and the fraction turned out to
//! depend on something the finding does not mention: whether the database has
//! ever been forked. Once it has, the guard compiles its **resolved** form, and
//! the compile is the largest single cost in the turn.
//!
//! # What it reports
//!
//! One line per fixture, `best` and `mean` over `--iterations` assertions
//! through the public surface — so the number includes the channel, the actor's
//! turn, the guard, the insert and its triggers, and the response. That is the
//! latency a caller waits on, which is the only figure the finding is about.
//!
//! Two fixtures, because the shape decides what the guard compiles:
//!
//! - **trunk** — never forked, so [`LineageShape::Trunk`] and the four-parameter
//! guard.
//! - **forked** — one branch exists and the write is still on the trunk, which
//! is `TrunkOnForked` and takes the resolved statement (0.15.2, D-244).
//!
//! # Reading it
//!
//! Measured on one Windows box, release build, 500 iterations, before and
//! after [D-248]:
//!
//! ```text
//! before after
//! trunk best 0.1842 mean 0.2705 best 0.0991 mean 0.1772
//! forked best 0.4011 mean 0.5060 best 0.1056 mean 0.1950
//! ```
//!
//! and the components, timed separately on a connection with the same file:
//! the `branches` query 10.8 µs, the guard's compile 3.9 µs on the trunk and
//! **151 µs** forked, `INSERT_LINK`'s compile 61 µs. So the forked write spent
//! nearly half its time compiling a statement it had compiled on the previous
//! call, and the trunk write about a third.
//!
//! The row worth reading twice is `forked`. A database with one abandoned
//! experiment in it paid **2.2×** the trunk's latency on every single-edge
//! write, and after this it pays 1.07× — the fork's cost was almost entirely
//! the guard's compile, not the guard.
//!
//! `best` is the honest figure here rather than `mean`: this is a latency floor
//! question, the fixture is small enough to be entirely in cache, and the mean
//! carries the OS's scheduling noise on a box that is also compiling. Both are
//! printed, and a run where they disagree by more than about 2× is a run that
//! was sharing the machine — see D-070 before quoting either.
//!
//! [D-248]: ../docs/architecture/s13-decision-register.md#d-248
//! [`LineageShape::Trunk`]: crate
use Instant;
use BranchId;
use EdgeAssertion;
use ;
const GENESIS: &str = "2020-01-01T00:00:00.000000Z";
async