liran-funaro / fabric-x-committer / 34139940249

91%

main: 90%

Build Type

push

github

Committed by liran-funaro

Commit Message

[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.
- 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):

    shape        keys/tx   allocs/tx        bytes/tx
    rw=1               1   13 -> 10         763 -> 742
    rw=4               4   30 -> 18       1,530 -> 1,440
    rw=4,bw=4          8   53 -> 29       2,525 -> 2,349

Three allocations per key, removed, which is what the diff predicts.

It saves no measurable time, and that is... (continued)

Coverage Stats

5 of 5 new or added lines in 1 file covered. (100.0%)

7 existing lines in 3 files now uncovered.

9290 of 10277 relevant lines covered (90.4%)

11382.96 hits per line