liran-funaro / fabric-x-committer / 34140483056
91%
main: 90%

LAST BUILD BRANCH: depgraph/size-scaling
DEFAULT BRANCH: main
Ran
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
34140483056

push

github

liran-funaro 
[coordinator] Hold a waiting key's first group inline

#### Type of change

- Improvement (improvement to code, performance, etc)
- Test update

#### Description

- `SimpleManager.checkTXFree` built four heap objects for every key of every transaction that
  found the key free: the `waiting` itself, its `queue` slice, a `waiterGroup`, and that group's
  `[]*TransactionNode`. All four had the same lifetime and all four became garbage together when
  the key was released, so a workload with no contention -- where a key is claimed once and
  released once -- paid four allocations per key to describe a queue of one.
  The first group and its first member are now inline fields of `waiting`, so that case costs one
  allocation. `add` is untouched: when a second group arrives its `append` sees a slice of length
  and capacity one and moves the queue to the heap exactly as before, so contended behaviour and
  ordering are unchanged. This is storage only -- same queue contents, same release order.
- Document what the graph costs per transaction in `docs/performance-tuning.md`, next to the two
  knobs that size it: the cost is per key rather than per transaction, so a transaction's cost
  tracks its operation count, and by four read-writes one machine's ceiling is the same order as
  the rate a large deployment reaches.
- Add `BenchmarkDependencyGraphBySize`, which measures the graph's cost per transaction as the
  transaction grows, for both managers. It differs from `BenchmarkDependencyGraph` in returning
  every released batch immediately as validated rather than holding it for a simulated ten
  seconds: that benchmark's latency is there to build a large waiting set, but it also means a
  dependent shape serialises behind it and a large `-benchtime` never finishes.

#### Additional details (Optional)

Allocations per transaction, which is what this change is about and what `-benchmem` reports
exactly (medians over six runs, 200,000 transactions each):

    s... (continued)
Source Files on build 34140483056
Detailed source file information is not available for this build.