Skip to content

⚡ optimize slice growth in evalRetrieve #159

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

Merged
copybara-service merged 2 commits into from
Feb 28, 2026
Merged

⚡ optimize slice growth in evalRetrieve #159

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c9009ba
perf: pre-allocate slice capacity in evalRetrieve
google-labs-jules[bot] Feb 28, 2026
bf16157
perf: pre-allocate slice capacity in evalRetrieve
google-labs-jules[bot] Feb 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion interpreter/expressions.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -191,7 +191,7 @@ func (i *interpreter) evalRetrieve(expr *model.Retrieve) (result.Value, error) {
return result.Value{}, fmt.Errorf("internal error - retrieve result type should be a list of named types, got %v", listResultType)
}

l := []result.Value{}
l := make([]result.Value, 0, len(got))
Copy link
Copy Markdown
Collaborator Author

@suyashkumar suyashkumar Feb 28, 2026

Choose a reason for hiding this comment

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

if we wanted to be optimal should we only set this if expr.Codes == nil? might not be worth the added complexity though

Copy link
Copy Markdown
Contributor

@google-labs-jules google-labs-jules bot Feb 28, 2026

Choose a reason for hiding this comment

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

That's a fair point. Pre-allocating the full length avoids all reallocations regardless of the filter's hit rate, which is generally faster. While it might over-allocate memory when filtering is active, len(got) is a safe upper bound. I agree that adding conditional logic might not be worth the complexity here unless we expect very large result sets with high filtering rates.

for _, c := range got {
r, err := unwrapContained(c)
if err != nil {
Expand Down
Loading