benchmark(endpoint): endpoint benchmarks

[ivankatliarchuk]

What does it do ?

Benchmark tests, full version here gofogo#62

The tests mimics our use case. In theory, the slice should be faster on smallet sets of properites, due to map hashing overhead and slice byt-by-byte comparison, same time technically there are all sorts of overhead

Motivation

This work related to #5814

Basically just adding benchamakrs for future. I think it is worth to keep it in the repo. And in follow-up we have baseline tests for comparison Slice vs Map

More

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

RandomAccess (GetProviderSpecificProperty)

Per-endpoint cost (ns/op divided by endpoint count, looking at 100k row):
  ┌────────────────┬─────────────┬───────────────────┐
  │ Properties set │ ns/endpoint │ Relative to set=0 │
  ├────────────────┼─────────────┼───────────────────┤
  │ 0              │ ~7.4 ns     │ 1.0x              │
  ├────────────────┼─────────────┼───────────────────┤
  │ 1              │ ~8.6 ns     │ 1.2x              │
  ├────────────────┼─────────────┼───────────────────┤
  │ 5              │ ~17.8 ns    │ 2.4x              │
  ├────────────────┼─────────────┼───────────────────┤
  │ 9              │ ~23.5 ns    │ 3.2x              │
  ├────────────────┼─────────────┼───────────────────┤
  │ 16             │ ~29.8 ns    │ 4.0x              │
  └────────────────┴─────────────┴───────────────────┘
  The cost scales linearly with the number of properties set — expected for a slice scan. At 16 properties the per-endpoint cost is ~4x that of an empty slice, which is the
  O(n) linear search behavior.

Delete (DeleteProviderSpecificProperty)

  1 allocation per iteration — the copy(endpoints, template) slice allocation. The delete operation itself is allocation-free (in-place slice manipulation).

  Per-endpoint cost (at 50k endpoints):
  ┌────────────────┬─────────────┬─────────────────────┐
  │ Properties set │ ns/endpoint │ Relative to props=0 │
  ├────────────────┼─────────────┼─────────────────────┤
  │ 0              │ ~5.8 ns     │ 1.0x                │
  ├────────────────┼─────────────┼─────────────────────┤
  │ 5              │ ~11.5 ns    │ 2.0x                │
  ├────────────────┼─────────────┼─────────────────────┤
  │ 10             │ ~15.9 ns    │ 2.8x                │
  └────────────────┴─────────────┴─────────────────────┘
  Same linear scan pattern — deleting from a longer slice costs proportionally more.

RandomAccess (GetProviderSpecificProperty)

ns per endpoint at each endpoint count:
  ┌───────────┬───────┬───────┬───────┬───────┬────────┐
  │ Endpoints │ set=0 │ set=1 │ set=5 │ set=9 │ set=16 │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 100       │ 6.7   │ 7.9   │ 15.0  │ 18.7  │ 24.4   │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 1,000     │ 6.7   │ 7.9   │ 15.0  │ 18.7  │ 24.5   │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 10,000    │ 6.8   │ 8.0   │ 15.1  │ 19.2  │ 25.3   │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 50,000    │ 7.1   │ 8.3   │ 16.1  │ 21.6  │ 28.1   │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 100,000   │ 7.4   │ 8.6   │ 17.8  │ 23.5  │ 29.8   │
  ├───────────┼───────┼───────┼───────┼───────┼────────┤
  │ 200,000   │ 9.4   │ 10.2  │ 19.5  │ 25.1  │ 30.2   │
  └───────────┴───────┴───────┴───────┴───────┴────────┘
  At small counts (100–10k), per-endpoint cost is flat — the working set fits in L1/L2 cache. Starting at ~50k endpoints, per-endpoint cost rises 20-40% depending on
  property count. At 200k with set=0, it's 9.4 ns vs 6.7 ns at 100 — a ~40% regression. This is cache pressure: the endpoint slice exceeds L2 cache and we start paying for L3/main memory latency.

Delete (DeleteProviderSpecificProperty)

 Delete — scaling by endpoint count

  ns per endpoint at each endpoint count:
  ┌───────────┬─────────┬─────────┬──────────┐
  │ Endpoints │ props=0 │ props=5 │ props=10 │
  ├───────────┼─────────┼─────────┼──────────┤
  │ 100       │ 6.4     │ 10.9    │ 13.6     │
  ├───────────┼─────────┼─────────┼──────────┤
  │ 300       │ 5.8     │ 10.7    │ 13.9     │
  ├───────────┼─────────┼─────────┼──────────┤
  │ 1,000     │ 5.7     │ 10.4    │ 14.0     │
  ├───────────┼─────────┼─────────┼──────────┤
  │ 10,000    │ 5.6     │ 10.0    │ 13.5     │
  ├───────────┼─────────┼─────────┼──────────┤
  │ 50,000    │ 5.8     │ 11.5    │ 15.9     │
  └───────────┴─────────┴─────────┴──────────┘
  Delete shows a flatter profile than random access. The per-endpoint cost barely changes from 100 to 50k. This is likely because the copy(endpoints, template) at the start
  of each iteration "warms" the cache — the sequential copy prefetches the memory that the subsequent delete loop will access.

[coveralls]

Pull Request Test Coverage Report for Build 21543315090

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 79.177%

---

Totals
Change from base Build 21510752750:	0.0%
Covered Lines:	16061
Relevant Lines:	20285

---

💛 - Coveralls

[szuecs]

should not we add here a b.ResetTimer() ?

[ivankatliarchuk]

I could add, but does not look where or not is required. Let me know, if you still this is required, I'll add it for extra protection.

The generateBenchmarkEndpoints call on line 79 is outside the b.Run sub-benchmark. Each sub-benchmark gets its own b with its own timer that starts when b.Run's function begins - so the setup cost of generateBenchmarkEndpoints is not measured.

Contrast with BenchmarkProviderSpecificDelete (line 106-107): there, generateBenchmarkEndpoints is called inside b.Run, so b.ResetTimer() is used to exclude that setup from the measurement.

[szuecs]

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: szuecs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [szuecs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment