Skip to content

Benchmark: optimal owned-type choices for AnalyticsEvent (SmolStr, SmallVec, etc.) #215

Description

@iainmcgin

Summary

Add a criterion benchmark that sweeps owned-type choices on the AnalyticsEvent workload (benchmarks/proto/bench_messages.proto) — SmolStr for strings, Bytes for bytes, SmallVec/BTreeMap for collections, an inline pointer for boxed sub-messages — to find the "optimal" balance of type choices for that message and quantify the wins over the all-default (String/Vec/HashMap/Box) baseline.

Why

The pluggable owned types (#206, #208, #209, #210) let a consumer trade memory/allocation behavior per field, but we have no measured guidance on which choices actually help and by how much for a realistic message. AnalyticsEvent is already benchmarked (benchmarks/buffa/benches/protobuf.rs), so it's a good subject: many short strings (inline-string candidates), repeated fields (inline-collection candidates), and nested messages (inline-pointer candidates).

Scope

  • Generate one or more AnalyticsEvent variants with different buffa_build type-choice configurations (all-default baseline; SmolStr strings; SmallVec repeated; BTreeMap maps; inline-SmallBox sub-messages; a "kitchen-sink optimal" combo).
  • Benchmark decode, encode, and (where relevant) construction/clone across the variants on the existing dataset.
  • Report the per-choice deltas and the best combination, with a short writeup of which choices paid off and which didn't.

Notes

  • Run on dedicated bare metal for stable absolute numbers — the shared homespace VM can't produce trustworthy criterion deltas (noisy neighbors / turbo). Use the metal-bench harness; pair each delta with a control variant the change doesn't touch.
  • Prior finding worth carrying in: from_wire/owned-type tricks are an owned-decode lever; the view path already borrows &str/&[u8] with no copy, so the wins show up in owned decode and construction, not in view-based reads. Expect short-string inlining (SmolStr) and inline collections to help most where the fields are small and numerous.

Follow-up to #156; pick up after #208 / #209 / #210 merge.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions