Breakdown generic writeOffsetTable - #643
Conversation
…and writePostingsOffsetTable Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
Any sense of how much? 10%? 20%? |
|
I don't have numbers for individual optimizations. All combined numbers is in this comment #627 (comment). I will try to get number for each optimizations. |
|
So the gains are mostly allocs. |
Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
gouthamve
left a comment
There was a problem hiding this comment.
LGTM, but I am not sure the minor improvement in allocs is worth this change.
|
|
||
| w.postings = append(w.postings, hashEntry{ | ||
| keys: []string{name, value}, | ||
| w.postings = append(w.postings, postingsHashEntry{ |
There was a problem hiding this comment.
I'm just surprised that this small change reduces allocs so much.
There was a problem hiding this comment.
Quite interesting indeed, but keep in mind that slice header is like ~16 bytes overall, so in some cases might be bigger than name or key (:
Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
I would still like to have it. Multiple small improvements will add up to a big gain. And the absolute gain from this PR will be bigger in different scenarios (more number of label-values and series than the benchmark). |
bwplotka
left a comment
There was a problem hiding this comment.
Make sesne to me. Might be small improvement but not much harm in code complexity.
This is a broken down piece of #627
With this, I am avoiding allocating slice headers for postings by having the name and value as separate fields. This saves quite some allocs.
[Don't merge until Prometheus 2.11 is out]