Repository navigation
Commit 3232f3f
committed
cachedb: an optional allocation-free read
get() must hand back a value the caller owns and pkg_free()s, so every
lookup on a hot path costs a pkg_malloc and a pkg_free that exist only to
satisfy that contract. Profiling the cachedb_perf read path put the
allocator at a fixed ~70 ns/op - 15% of a 470 ns lookup over 50 000
entries, 30% of a 236 ns one when the working set is cache resident -
while memcpy never appeared at all.
Add an optional endpoint that reads into a buffer the caller already
owns: no allocation, and one copy instead of two. It is advertised by
CACHEDB_CAP_GET_BUF, so a caller uses it only where a backend offers it
and keeps get() as the fallback; nothing about the existing endpoint
changes, and no backend is obliged to implement the new one.
The contract is written for the failure cases, because those are what a
caller gets wrong: the buffer must be private to the calling process, it
may be written speculatively and abandoned so its contents are undefined
on any non-hit, *vlen and *needed are zeroed before anything else so an
ignored return code yields a zero length rather than an uninitialised
one, and a value that does not fit reports the size it would need in
*needed while leaving *vlen at 0 - {buf, *vlen} is always a valid str.
A hit is 0 here, unlike get(), which is called out in the comment.
CACHEDB_CAP_GET_BUF answers a runtime question - whether the backend a
caller happens to be configured against implements the endpoint. It
cannot answer the one a module has to settle first: whether the core it
is being compiled against has the endpoint at all. get_buf is a member of
cachedb_funcs, so referencing it against an older core is a compile error
rather than a failed test, and the capability is an enum constant,
invisible to the preprocessor. So there is a plain define beside it, and
a module can compile against either core and pick the faster path up on
its own. The runtime check is still required and the comment says so - a
core may carry the endpoint while the backend in use does not implement
it.
The first implementation is cachedb_perf, in the following commit.1 parent 5a7f3a6 commit 3232f3f
2 files changed
Lines changed: 52 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
162 | 162 | | |
163 | 163 | | |
164 | 164 | | |
| 165 | + | |
165 | 166 | | |
| 167 | + | |
| 168 | + | |
| 169 | + | |
| 170 | + | |
| 171 | + | |
| 172 | + | |
| 173 | + | |
| 174 | + | |
| 175 | + | |
| 176 | + | |
| 177 | + | |
| 178 | + | |
| 179 | + | |
| 180 | + | |
| 181 | + | |
| 182 | + | |
| 183 | + | |
| 184 | + | |
| 185 | + | |
| 186 | + | |
| 187 | + | |
| 188 | + | |
| 189 | + | |
| 190 | + | |
| 191 | + | |
| 192 | + | |
| 193 | + | |
| 194 | + | |
166 | 195 | | |
167 | 196 | | |
168 | 197 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
51 | 51 | | |
52 | 52 | | |
53 | 53 | | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
54 | 58 | | |
55 | 59 | | |
| 60 | + | |
| 61 | + | |
| 62 | + | |
| 63 | + | |
| 64 | + | |
| 65 | + | |
| 66 | + | |
| 67 | + | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
| 78 | + | |
56 | 79 | | |
57 | 80 | | |
58 | 81 | | |
| |||
0 commit comments