Skip to content

MQE: eliminate loops in BucketedPool #10199

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 3 commits into from
Dec 10, 2024
Merged

MQE: eliminate loops in BucketedPool #10199

merged 3 commits into from
Dec 10, 2024

Conversation

charleskorn
Copy link
Contributor

@charleskorn charleskorn commented Dec 10, 2024 •
edited
Loading

What this PR does

This PR eliminates the use of loops in BucketedPool. This gives a very mild speedup (<1%) to queries with many steps and many series.

It also removes the panics in both ring buffer's Append and Use methods. It's possible that the conditions that previously would have caused a panic could happen in the real world if a subquery selected enough points that it exceeded the maximum size of a slice returned from the FPoint or HPoint pool, so it seems safer to return an error here rather than crashing the process.

Which issue(s) this PR fixes or relates to

(none)

Checklist

  • Tests updated.
  • [n/a] Documentation added.
  • [n/a] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX].
  • [n/a] about-versioning.md updated with experimental features.

@charleskorn charleskorn mentioned this pull request Dec 10, 2024
Open
@charleskorn charleskorn marked this pull request as ready for review December 10, 2024 03:40
@charleskorn charleskorn requested a review from a team as a code owner December 10, 2024 03:40
jhesketh
jhesketh reviewed Dec 10, 2024
View reviewed changes
Copy link
Contributor

@jhesketh jhesketh left a comment

Choose a reason for hiding this comment

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

I'd be curious to see a benchmark for this if possible please :-).

Also, regarding the power of 2 checks in the buffer, we could grow the capacity of the returned slice to the next power of 2. It doesn't help the pool or anything, but we can still potentially process it. We'd need some kind of additional limit for reasonableness though so it might not be worth it so long as the pool sizes are reasonable themselves.

@charleskorn
Copy link
Contributor Author

We'd need some kind of additional limit for reasonableness though so it might not be worth it so long as the pool sizes are reasonable themselves.

I think the pool sizes are already reasonable themselves - and if we start running into this in the real world then we can easily adjust the pool limit.

@charleskorn
Copy link
Contributor Author

I'd be curious to see a benchmark for this if possible please :-).

Most of our benchmarks see very mild impact (<1%), but for queries with many steps and many series, the impact is noticeable:

                                                                     │  before.txt  │             after.txt              │
                                                                     │    sec/op    │    sec/op     vs base              │
Query/a_2000,_range_query_with_100_steps/engine=Mimir-10                20.07m ± 3%   19.31m ±  1%  -3.79% (p=0.002 n=6)
Query/a_2000,_range_query_with_1000_steps/engine=Mimir-10               95.23m ± 5%   93.46m ±  4%  -1.87% (p=0.041 n=6)
Query/nh_2000,_range_query_with_100_steps/engine=Mimir-10               154.7m ± 1%   152.1m ±  1%  -1.74% (p=0.002 n=6)
Query/nh_2000,_range_query_with_1000_steps/engine=Mimir-10              832.5m ± 2%   810.3m ±  7%       ~ (p=0.065 n=6)

jhesketh
jhesketh approved these changes Dec 10, 2024
View reviewed changes
Copy link
Contributor

@jhesketh jhesketh left a comment

Choose a reason for hiding this comment

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

Neat, thanks!

@charleskorn charleskorn merged commit 5b1184e into main Dec 10, 2024
29 checks passed
@charleskorn charleskorn deleted the charleskorn/pooling branch December 10, 2024 05:55
@jhesketh
Copy link
Contributor

This introduced a bug fixed in #10261

@jhesketh jhesketh mentioned this pull request Dec 17, 2024
Merged
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jhesketh jhesketh jhesketh approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@charleskorn @jhesketh