apache / apache/beam

[Task][Go SDK][Perf]: Make and use a general []byte buffer allocation pool for the SDK.

Open
#25,522 6 comments 0 reactions 1 assignee Claimed by @yyy1000 View on GitHub
go P2 performance task
Dominant language
Java
Stars
8.7k
Forks
4.7k
Avg merge
1d 20h
Merged PRs (30d)
196

Description

### What needs to happen?

Replace all small []byte, or bytes.Buffer uses with a central `sync.Pool` allocated "buffer" package, like

https://cs.opensource.google/go/x/exp/+/f062dba9:slog/internal/buffer/buffer.go;bpv=1;bpt=1

or

https://github.com/golang/go/blob/master/src/log/log.go#L165

https://pkg.go.dev/sync#Pool are weak reference pools meaning that buffers in the pool may be freed at during the next GC if appropriate.

While some unsafe strategies were used as well, through the [ioutilx package read](https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/util/ioutilx/read.go#L54) and [write](https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/util/ioutilx/write.go#L27) calls to avoid allocations, this remains slightly risky, so uses there are a reasonable priority.

But generally, [uses of bytes.Buffer](https://github.com/apache/beam/search?l=Go&q=bytes.Buffer) or arbitrary lengths but known lifetime uses of [make([]byte)]( https://github.com/apache/beam/search?l=Go&q=make%28%5B%5Dbyte)

Some bytes.Buffer replacements would require this new Buffer to support the io.Reader interface as well.

In particular, targeting the uses in the exec and harness packages would likely be the most fruitful.

It would be worth having a moderate scale benchmark to validate the before and after performance of this change, with appropriate heap and CPU profiles.

-----
Notionally the benefits would be a reduction in byte buffer allocations to the heap through re-use, while also enabling certain levels of inlining, though this would require more explicit use of the new buffer type instead of using the interfaces.

Note that Go also remains a garbage collected language, so not all uses from the pool need to be freed. They can leak and be GC'd normally.

### Issue Priority

Priority: 3 (nice-to-have improvement)

### Issue Components

- [ ] Component: Python SDK
- [ ] Component: Java SDK
- [X] Component: Go SDK
- [ ] Component: Typescript SDK
- [ ] Component: IO connector
- [ ] Component: Beam examples
- [ ] Component: Beam playground
- [ ] Component: Beam katas
- [ ] Component: Website
- [ ] Component: Spark Runner
- [ ] Component: Flink Runner
- [ ] Component: Samza Runner
- [ ] Component: Twister2 Runner
- [ ] Component: Hazelcast Jet Runner
- [ ] Component: Google Cloud Dataflow Runner

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.