Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use zeropool for postings cache key building #4869

Merged
merged 3 commits into from
Apr 28, 2023

Conversation

colega
Copy link
Contributor

@colega colega commented Apr 28, 2023

What this PR does

Late feedback on #4861, so I decided to open a PR instead of commenting.

Zeropool is useful when we can't retain the pointer to put it back into the pool, but when we can it causes an unnecessary overhead of a second pool.

This saves some nanoseconds, without an allocations change

goos: linux
goarch: amd64
pkg: github.com/grafana/mimir/pkg/storegateway/indexcache cpu: 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz
                                     │   main.txt   │               new.txt                │
                                     │    sec/op    │    sec/op     vs base                │
StringCacheKeys/postings-16            1.011µ ±  0%   1.001µ ±  3%   -0.94% (p=0.033 n=10)
StringCacheKeys/series_ref-16          133.9n ± 13%   120.5n ±  9%   -9.97% (p=0.000 n=10)
StringCacheKeys/expanded_postings-16   418.0n ±  7%   328.2n ± 21%  -21.47% (p=0.000 n=10)
geomean                                383.8n         340.8n        -11.20%

Which issue(s) this PR fixes or relates to

None, followup on #4861

Checklist

  • Tests updated
  • Documentation added
  • CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

Zeropool is useful when we can't retain the pointer to put it back into
the pool, but when we can it causes an unnecessary overhead of a second
pool.

This saves some nanoseconds, without an allocations change

goos: linux
goarch: amd64
pkg: github.com/grafana/mimir/pkg/storegateway/indexcache
cpu: 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz
                                     │   main.txt   │               new.txt                │
                                     │    sec/op    │    sec/op     vs base                │
StringCacheKeys/postings-16            1.011µ ±  0%   1.001µ ±  3%   -0.94% (p=0.033 n=10)
StringCacheKeys/series_ref-16          133.9n ± 13%   120.5n ±  9%   -9.97% (p=0.000 n=10)
StringCacheKeys/expanded_postings-16   418.0n ±  7%   328.2n ± 21%  -21.47% (p=0.000 n=10)
geomean                                383.8n         340.8n        -11.20%

Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
@colega colega requested a review from pracucci April 28, 2023 08:34
@colega colega marked this pull request as ready for review April 28, 2023 08:34
@colega colega requested a review from a team as a code owner April 28, 2023 08:34
@@ -32,10 +32,10 @@ const (
)

var (
postingsCacheKeyLabelHashBufferPool = zeropool.New[[]byte](func() []byte {
// We assume the label name/value pair is typically not longer than 1KB.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't you like my comment? :D

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I initially changed to return new([]byte) and allocate a max(expectedLen, 1024) in the usage, but that seemed unnecessary complex to me, so I lost the comment when I switched back. Recovered it now :)

Signed-off-by: Oleg Zaytsev <mail@olegzaytsev.com>
@pracucci pracucci enabled auto-merge (squash) April 28, 2023 09:14
@pracucci pracucci merged commit 044ab8c into main Apr 28, 2023
@pracucci pracucci deleted the dont-use-zeropool-for-postings-cache-key-building branch April 28, 2023 09:28
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.

2 participants