Skip to content

feat: support value-receiver type summary#129

Open
proost wants to merge 3 commits intoapache:mainfrom
proost:feat-support-value-type-receiver-tuple-sketch
Open

feat: support value-receiver type summary#129
proost wants to merge 3 commits intoapache:mainfrom
proost:feat-support-value-type-receiver-tuple-sketch

Conversation

@proost
Copy link
Member

@proost proost commented Feb 25, 2026

We use tuple sketch a lot. One of teams use tuple sketch extremely. One application has many tuple sketches, that each one has lots of summaries.

So It makes a more than billion live objects in heap. So every GC period, especially Marking phase, go runtime uses too many CPU usages as well as it makes longer stop the world.

So I propose supporting value-type receiver summary using "UpdateFunc".

Idea is simple:

  1. we use "entry" to store summary and hash. so if "Summary" implementation is value, we can inline it.
  2. we store list of "entry" in "slab" like. So in marking phase, go runtime mark it as just a couple of objects.

Normally, it is not that burden to allocate millions ~ less than billions live objects in heap. So current interface is ok. Also current interface is easy to use and easy to understand.

Here is benchmark result:

goos: darwin
goarch: arm64
pkg: github.com/apache/datasketches-go/tuple
cpu: Apple M4 Pro
BenchmarkUpdateSketch_PointerSummary
BenchmarkUpdateSketch_PointerSummary-12    	    3956	    301095 ns/op	  318668 B/op	    8917 allocs/op
PASS


goos: darwin
goarch: arm64
pkg: github.com/apache/datasketches-go/tuple
cpu: Apple M4 Pro
BenchmarkUpdateSketch_ValueSummary
BenchmarkUpdateSketch_ValueSummary-12    	    5446	    213742 ns/op	  280724 B/op	       8 allocs/op
PASS

Benchmark code is included in this PR.

@proost proost self-assigned this Feb 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant