Skip to content

Conversation

@anacrolix
Copy link

Reduces allocations by 75% for a single sort field.

Before:
profile002

After:
profile001

Reduces allocations by 75% for a single sort field.
@mschoch
Copy link
Member

mschoch commented Nov 8, 2022

This looks good to me.

As I understand it, the allocations we avoid are here:

And the usage pattern is already one where we expect the same fields.

Can you share what the workload is that you used to generate the profiles? Would it be appropriate as a benchmark in the package?

@anacrolix
Copy link
Author

That's right. The workload is an index with a text field and a numeric field. I'm doing a top N search, matching on the text field and sorting on the numeric field. I don't think it matters but the query has MatchQueryOperatorAnd.

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